Use cloud object storage on AWS
The best practice for allowing workloads within your EKS cluster access to cloud services is by using IAM roles. For ArcGIS Enterprise, you can allow access to the organization’s cloud object store and backup stores in AWS S3 buckets through either pod identity or node group-based IAM role.
It is recommended that your organization use pod identity for handling authentication of Kubernetes workloads, because it allows the most granular control over the permissions granted to pods. If your organization is using node group-based IAM role to control permissions, it is recommended that you migrate to using pod identities when you update or upgrade.
Use EKS Pod Identity
ArcGIS Enterprise on Kubernetes uses different service accounts for workloads based on required permissions to the Kubernetes API server. These service accounts also require different permissions when accessing integrated cloud services. You can use pod identity to create an association between each service account and an IAM role with the required permissions.
Important:
Before deploying ArcGIS Enterprise on Kubernetes or creating other dependencies in AWS, the EKS Pod Identity Agent add-on must be installed in the cluster. For instructions, see Set up the Amazon EKS Pod Identity Agent.
IAM roles and policies
Before deploying and configuring ArcGIS Enterprise on Kubernetes with an AWS S3 cloud object store and backup store, configure the following IAM roles and policies:
Read-write access to cloud object store and backup stores
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "s3:PutObject", "s3:GetObject", "s3:ListBucket", "s3:DeleteObject", "s3:GetLifecycleConfiguration", "s3:PutLifecycleConfiguration", "s3:ListMultipartUploadParts", "s3:GetBucketLocation", "s3:AbortMultipartUpload" ], "Resource": [ "arn:aws:s3:::<cloudObjectStoreBucket>/*", "arn:aws:s3:::<cloudObjectStoreBucket>", "arn:aws:s3:::<backupStoreBucket>/*", "arn:aws:s3:::<backupStoreBucket>" ] } ] }Read-write access to cloud object store
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "s3:PutObject", "s3:GetObject", "s3:ListBucket", "s3:DeleteObject", "s3:GetLifecycleConfiguration", "s3:PutLifecycleConfiguration", "s3:ListMultipartUploadParts", "s3:GetBucketLocation", "s3:AbortMultipartUpload" ], "Resource": [ "arn:aws:s3:::<cloudObjectStoreBucket>/*", "arn:aws:s3:::<cloudObjectStoreBucket>" ] } ] }Read-only access to cloud object store
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "s3:GetObject", "s3:ListBucket", "s3:GetBucketLocation" ], "Resource": [ "arn:aws:s3:::<cloudObjectStoreBucket>/*", "arn:aws:s3:::<cloudObjectStoreBucket>" ] } ] }
Note:
Additional policies can be created under each IAM role to allow access to user storage buckets in addition to the system object and backup stores.
Pod identity associations
Within the EKS cluster, add pod identity associations to map each service account to the appropriate IAM role. For instructions, see the AWS documentation topic Assign an IAM role to a Kubernetes service account.
The following table lists the required IAM role for each service account:
| Service account | IAM role |
|---|---|
| arcgis-admin-serviceaccount | Read-write access to cloud object and backup stores |
| arcgis-disasterrecovery-serviceaccount | Read-write access to cloud object and backup stores |
| arcgis-spatiotemporalindex-serviceaccount | Read-write access to cloud object and backup stores |
| arcgis-cloudservice-readwrite-serviceaccount | Read-write access to cloud object store |
| arcgis-cloudservice-readonly-serviceaccount | Read-only access to cloud object store |
The service account names on the table reflect the default site name, arcgis. If you configured a different site name, that name will be used as the service account prefix instead of arcgis. Review your current organization settings if you are unsure of the site name for your organization.
Use node group-based IAM role
If you cannot use pod identity, ArcGIS Enterprise on Kubernetes can also use an IAM role assigned to the Kubernetes cluster’s node group for permission to access cloud services.
Caution:
When you use a node group-based IAM role, all workloads running on those nodes have equivalent permissions. This will result in some workloads having permissions they do not require.
To use node group-based IAM role, create a single combined read-write policy:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:PutObject",
"s3:GetObject",
"s3:ListBucket",
"s3:DeleteObject",
"s3:GetLifecycleConfiguration",
"s3:PutLifecycleConfiguration",
"s3:ListMultipartUploadParts",
"s3:GetBucketLocation",
"s3:AbortMultipartUpload"
],
"Resource": [
"arn:aws:s3:::<systemObjectStoreBucket>/*",
"arn:aws:s3:::<systemObjectStoreBucket>",
"arn:aws:s3:::<backupStoreBucket>/*",
"arn:aws:s3:::<backupStoreBucket>"
]
}
]
}
Migrate to EKS Pod Identity
Organizations that use a node group-based IAM role should plan to migrate to EKS pod identity during an organization upgrade or update. This minimizes disruption because all pods require a restart after the pod identity associations are created. Pods are restarted automatically during organization updates and upgrades.
Complete the following steps to migrate to using pod identity to control permissions:
Install the EKS pod identity agent add-on.
Create the required IAM roles and pod identity associations.
Upgrade ArcGIS Enterprise.
Verify that services and critical workflows are functional.
Remove the IAM policy from the node group IAM role that allows access to S3 storage.
Verify again that services and critical workloads are functional.
If an issue is found at this step, re-add the original IAM policy to the node group IAM role. This will allow you to regain functionality while you complete further review of the add on status, pod identity IAM roles and policies, and pod identity associations.