This documentation is a draft for private preview for regions in the AWS European Sovereign Cloud. Documentation content will continue to evolve. Published: January 12, 2026.

Help improve this page

To contribute to this user guide, choose the Edit this page on GitHub link that is located in the right pane of every page.

Register target clusters

Register clusters to enable Argo CD to deploy applications to them. You can register the same cluster where Argo CD is running (local cluster) or remote clusters in different accounts or regions.

Prerequisites

Register the local cluster

To deploy applications to the same cluster where Argo CD is running, register it as a deployment target.

Using the Argo CD CLI:

argocd cluster add <cluster-context-name> \
  --aws-cluster-name arn:aws:eks:us-west-2:111122223333:cluster/my-cluster \
  --name local-cluster

Using a Kubernetes Secret:

apiVersion: v1
kind: Secret
metadata:
  name: local-cluster
  namespace: argocd
  labels:
    argocd.argoproj.io/secret-type: cluster
stringData:
  name: local-cluster
  server: arn:aws:eks:us-west-2:111122223333:cluster/my-cluster
  project: default

Apply the configuration:

kubectl apply -f local-cluster.yaml

Register remote clusters

To deploy to remote clusters:

Step 1: Create the access entry on the remote cluster

Replace region-code with the AWS Region that your remote cluster is in, replace remote-cluster with the name of your remote cluster, and replace the ARN with your Argo CD capability role ARN.

aws eks create-access-entry \
  --region region-code \
  --cluster-name remote-cluster \
  --principal-arn arn:aws:iam::[.replaceable]111122223333:role/ArgoCDCapabilityRole \
  --type STANDARD

Step 2: Associate an access policy with Kubernetes RBAC permissions

The Access Entry requires Kubernetes RBAC permissions for Argo CD to deploy applications. For getting started quickly, you can use the AmazonEKSClusterAdminPolicy:

aws eks associate-access-policy \
  --region region-code \
  --cluster-name remote-cluster \
  --principal-arn arn:aws:iam::[.replaceable]111122223333:role/ArgoCDCapabilityRole \
  --policy-arn arn:aws:eks::aws:cluster-access-policy/AmazonEKSClusterAdminPolicy \
  --access-scope type=cluster

Step 3: Register the cluster in Argo CD

Using the Argo CD CLI:

argocd cluster add <cluster-context-name> \
  --aws-cluster-name arn:aws:eks:us-west-2:111122223333:cluster/remote-cluster \
  --name remote-cluster

Using a Kubernetes Secret:

apiVersion: v1
kind: Secret
metadata:
  name: remote-cluster
  namespace: argocd
  labels:
    argocd.argoproj.io/secret-type: cluster
stringData:
  name: remote-cluster
  server: arn:aws:eks:us-west-2:111122223333:cluster/remote-cluster
  project: default

Apply the configuration:

kubectl apply -f remote-cluster.yaml

Cross-account clusters

To deploy to clusters in different AWS accounts:

No additional IAM role creation or trust policy configuration is required—EKS Access Entries handle cross-account access.

The cluster ARN format includes the region, so cross-region deployments use the same process as same-region deployments.

Verify cluster registration

View registered clusters:

kubectl get secrets -n argocd -l argocd.argoproj.io/secret-type=cluster

Or check cluster status in the Argo CD UI under Settings → Clusters.

Private clusters

The Argo CD capability provides transparent access to fully private EKS clusters without requiring VPC peering or specialized networking configuration.

AWS manages connectivity between the Argo CD capability and private remote clusters automatically.

Simply register the private cluster using its ARN—no additional networking setup required.

Access Entry RBAC requirements

When you create an Argo CD capability, an EKS Access Entry is automatically created for the Capability Role, but no Kubernetes RBAC permissions are granted by default. This intentional design follows the principle of least privilege—different use cases require different permissions.

For example: * If you use the cluster only as an Argo CD hub to manage remote clusters, it doesn’t need local deployment permissions * If you deploy applications locally, it needs read access cluster-wide and write access to specific namespaces * If you need to create CRDs, it requires additional cluster-admin permissions

You must explicitly configure the permissions Argo CD needs based on your requirements.

Minimum permissions for Argo CD

Argo CD needs two types of permissions to function without errors:

Read permissions (cluster-wide): Argo CD must be able to read all resource types and Custom Resource Definitions (CRDs) across the cluster for:

Write permissions (namespace-specific): Argo CD needs create, update, and delete permissions for resources defined in Applications:

Quick setup

For getting started quickly, testing, or development environments, use AmazonEKSClusterAdminPolicy:

aws eks associate-access-policy \
  --region region-code \
  --cluster-name my-cluster \
  --principal-arn arn:aws:iam::[.replaceable]111122223333:role/ArgoCDCapabilityRole \
  --policy-arn arn:aws:eks::aws:cluster-access-policy/AmazonEKSClusterAdminPolicy \
  --access-scope type=cluster

Production setup with least privilege

For production environments, create custom Kubernetes RBAC that grants:

Step 1: Associate Access Entry with a custom Kubernetes group

aws eks associate-access-policy \
  --region region-code \
  --cluster-name my-cluster \
  --principal-arn arn:aws:iam::[.replaceable]111122223333:role/ArgoCDCapabilityRole \
  --policy-arn arn:aws:eks::aws:cluster-access-policy/AmazonEKSEditPolicy \
  --access-scope type=namespace,namespaces=app-namespace
         

Step 2: Create ClusterRole for read access

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: argocd-read-all
rules:
# Read access to all resources for discovery and health checks
- apiGroups: ["*"]
  resources: ["*"]
  verbs: ["get", "list", "watch"]

Step 3: Create Role for write access to application namespaces

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: argocd-deploy
  namespace: app-namespace
rules:
# Full access to deploy application resources
- apiGroups: ["*"]
  resources: ["*"]
  verbs: ["*"]

Step 4: Bind roles to the Kubernetes group

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: argocd-read-all
subjects:
- kind: Group
  name: eks-access-entry:arn:aws:iam::111122223333:role/ArgoCDCapabilityRole
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: argocd-read-all
  apiGroup: rbac.authorization.k8s.io
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: argocd-deploy
  namespace: app-namespace
subjects:
- kind: Group
  name: eks-access-entry:arn:aws:iam::111122223333:role/ArgoCDCapabilityRole
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: argocd-deploy
  apiGroup: rbac.authorization.k8s.io

Restrict cluster access with Projects

Use Projects to control which clusters and namespaces Applications can deploy to by configuring the allowed target clusters and namespaces in spec.destinations:

apiVersion: argoproj.io/v1alpha1
kind: AppProject
metadata:
  name: production
  namespace: argocd
spec:
  destinations:
  - server: arn:aws:eks:us-west-2:111122223333:cluster/prod-cluster
    namespace: '*'
  - server: arn:aws:eks:eu-west-1:111122223333:cluster/prod-eu-cluster
    namespace: '*'
  sourceRepos:
  - 'https://github.com/example/production-apps'

For details, see Working with Argo CD Projects.

Additional resources