How to register EKS clusters in Argo CD without static kubeconfigs
Argo CD can manage several EKS clusters across accounts without storing a long-lived kubeconfig in Kubernetes. The supported approach is an EKS cluster secret that sets execProviderConfig to call argocd-k8s-auth, which obtains a short-lived token at sync time. The Argo CD pods authenticate to AWS through IRSA or the EKS Pod Identity agent, so the credential that reaches each cluster is generated on demand rather than copied into a Secret. The declarative setup guide is the source for this method, and the example in it is the best starting point for the manifests your team writes.
The pattern has two identity layers. The application controller, ApplicationSet controller and server service accounts each need to assume a management role through IRSA or Pod Identity, and that role must trust those service accounts. For clusters in other accounts, the management role is granted sts:AssumeRole on a role in each target account, and each cluster role is then mapped to Kubernetes access. Decide early which account owns the management role, how many accounts it can reach, and who may change the trust policy, because that role becomes the most sensitive identity in the Argo CD installation.
Before you rely on this design, confirm three things with your own environment: that every controller and server service account is covered by the trust relationship, that the argocd-k8s-auth version in your image matches the Argo CD release you run, and that you can register a test cluster and see a sync succeed without any static kubeconfig Secret present. Keep the aws-auth ConfigMap path out of new work, since the guide describes it as deprecated in favor of EKS access entries.
What you need before registering an EKS cluster
Registering an EKS cluster touches three places: the Argo CD installation, the AWS account that hosts each cluster, and the network path between them. Each card below is a decision or check to settle before you run any registration, so that the cluster secret you create later works on the first attempt.
Argo CD version and support window
Pick the Argo CD minor version you will run, then confirm it is still in the project's patch window before you build on it. The release process says only the three most recent minor versions receive patch releases, and a minor ships four times a year. Check the current list on the release page and confirm the exact argocd-k8s-auth version your Argo CD release expects with the vendor documentation. Record both versions in your runbook.
Management role and trust
Decide which IAM role Argo CD uses to call AWS, and confirm that IRSA or the EKS Pod Identity agent is working on the management cluster. The role must trust the application controller, ApplicationSet controller and server service accounts. Without that trust, the exec provider has no identity to assume. Note which accounts will hold this role, because cross-account chaining starts here.
OIDC provider or Pod Identity readiness
For IRSA, the management cluster needs an IAM OIDC identity provider registered in its account. For EKS Pod Identity, the Pod Identity agent add-on must be installed and healthy. Check which mechanism your platform team already runs, because mixing both on one service account adds troubleshooting work. Confirm the service account names and namespaces used by your Argo CD install before you write any trust policy.
Cluster roles in each account
Each managed EKS cluster needs an IAM role that the management role can assume, and that role needs an EKS access entry or a legacy aws-auth mapping that grants the Kubernetes permissions Argo CD needs. The example in the setup guide associates AmazonEKSClusterAdminPolicy, which grants cluster-admin. Treat that as a starting point to narrow, not a default to ship. Confirm which access entry type your cluster supports before you choose the mechanism.
API endpoint reachability
Confirm the private or public API endpoint of each EKS cluster and the network path from the Argo CD cluster to it. Check security groups, VPC routing, peering or transit gateway routes, and any DNS resolution for private endpoints. Argo CD must reach the endpoint on the cluster's API port, and a failed route shows up as a registration or sync error that looks like an authentication problem. Test reachability from a pod that runs under the same service account Argo CD uses.
Binary availability for the exec provider
The argocd-k8s-auth binary must be present in the image or filesystem of every Argo CD component that calls it, including the application controller, ApplicationSet controller and server. Check that the image you deploy includes it, or that your build adds it at a known path. Confirm the exact version and any required flags with the vendor documentation, and test a token request from each component before you register any cluster.
Configure the management role, role chain and cluster secrets
This sequence builds the AWS trust path that lets Argo CD reach each EKS cluster without static kubeconfigs, from the pod identity on the management cluster through role chaining and cluster access to a registered cluster Secret. Each step closes with a check so failures surface before Argo CD depends on the path.
Create the management role and its trust
The platform team creates one IAM role in the account that hosts the Argo CD management cluster. Its trust policy allows the Argo CD application controller, ApplicationSet controller and server service accounts to assume it, either through IAM Roles for Service Accounts (IRSA) or through the EKS Pod Identity agent, depending on how the management cluster is set up. Confirm the exact trust statements against the Argo CD declarative setup guide for your chosen mechanism. The step is complete when a debug pod using each service account can obtain credentials for this role, which you can check by running the AWS CLI identity call inside the pod and seeing the management role ARN rather than the node role.
Grant sts:AssumeRole on each target cluster role
For every EKS cluster in every account, the team creates or identifies the cluster access role that Kubernetes will see, then adds a trust statement to that role so the management role can assume it. The management role also needs an sts:AssumeRole permission for each of those target roles. Keep one target role per cluster or per environment where possible, so a compromised registration reaches only the clusters it was meant for. The check is a manual assume-role call from the management pod against one target role, returning temporary credentials whose identity is the target role.
Map the cluster role with an EKS access entry
On each target cluster, the cluster administrator creates an EKS access entry for the target role. The access entry is the current mechanism for granting cluster access, and the aws-auth ConfigMap is deprecated, so avoid adding new mappings there. The Argo CD guide's example associates AmazonEKSClusterAdminPolicy, which grants cluster-admin. Use it only when Argo CD is intended to manage every namespace and cluster-scoped resource on that cluster. For tenant-scoped or narrower use, choose a more limited access policy or a custom Kubernetes group, and confirm the policy contents with AWS documentation before you attach it. The check is that the access entry appears in the cluster's access list with the intended policy and scope.
Confirm the target role can list the cluster
Before Argo CD is involved, an operator tests the path end to end using the same role chain Argo CD will use. From the management pod, assume the target role and generate a kubeconfig token through the AWS CLI, then run a read-only command such as listing namespaces. This proves that the trust policy, the AssumeRole permission and the access entry work together. If the call returns Unauthorized or AccessDenied, check the access entry principal ARN against the target role ARN first, since a mismatch is the most common cause. The step closes when the namespace list returns from the target cluster.
Write the cluster Secret with execProviderConfig
The platform team writes a Kubernetes Secret in the Argo CD namespace with the label that marks it as a cluster registration, a server URL for the cluster API endpoint and a config block. For the current approach, use execProviderConfig to call argocd-k8s-auth so that Argo CD requests a short-lived token at sync time. Set the role ARN to the target role and the cluster name to the EKS cluster. Keep the Secret in Git only if it is encrypted or managed by a secret operator, since the cluster endpoint and role ARN are account-identifying. The Secret is declarative, so store it under the same review controls as other Argo CD configuration. Use awsAuthConfig only where your existing setup already depends on it and you have a migration plan.
Verify the registration from the Argo CD pod
After Argo CD reads the Secret, check the cluster from the Argo CD side. Confirm the cluster appears in the settings and shows a successful connection status. Then, from the application controller pod, run the Argo CD CLI or an equivalent check to list the cluster and confirm it reports a server version. For a more direct proof, inspect the controller logs for authentication errors after a short sync interval. A healthy registration shows the cluster as Successful with no token or AccessDenied messages. If the check fails, go back to the earlier step where the path broke rather than widening permissions on the management role.
Record the trust chain for reviewers
The team documents each link in the chain: the management role, its trust for the three Argo CD service accounts, each target role, each access entry and its policy, and the Secret that references them. Store this record with the change request for the Argo CD configuration, so reviewers can trace which account and cluster each registration reaches. Ask your AWS and Argo CD administrators to confirm the list of authorized target roles before go-live, and repeat the verification step after any role or policy change.
Choosing between IRSA and EKS Pod Identity for the management role
IRSA (IAM Roles for Service Accounts) lets a Kubernetes service account assume an IAM role through the cluster's OIDC identity provider. Each EKS cluster has its own OIDC issuer, so the management role's trust policy must name the federated identity of every management cluster that hosts Argo CD. EKS Pod Identity uses a separate agent that runs on the cluster and exchanges the pod's token for role credentials through an association between a service account and an IAM role. The trust policy trusts the EKS Pod Identity service principal, and the association is created in the EKS API rather than in the role's trust relationship.
- Trust policy scope: IRSA trust policies list each cluster's OIDC provider and the exact service account subjects, so every new management cluster means an edit to the role.
- Service account annotations: IRSA requires an
eks.amazonaws.com/role-arnannotation on each service account the controller, ApplicationSet controller and server use. - Association setup: Pod Identity moves the binding out of annotations and into an association object per service account and namespace, which you create with the EKS API or console.
- Agent dependency: Pod Identity needs the EKS Pod Identity agent add-on running on the management cluster, so it becomes part of cluster health and upgrades.
- Environment fit: Teams that already run IRSA across many clusters often keep it; teams starting fresh or standardizing on managed associations often evaluate Pod Identity first.
Before committing, confirm the current Pod Identity requirements, supported cluster versions and trust policy format in the AWS documentation for your region and Kubernetes version.
The practical difference shows up in the role's trust policy. With IRSA, the trust statement uses a web identity condition that matches the cluster's OIDC issuer and the expected sub claim for each Argo CD service account. Adding a management cluster requires registering its OIDC provider with IAM and extending that statement. With Pod Identity, the trust statement names the EKS Pod Identity principal and typically includes session tag handling, so a single role can be reused across clusters where the associations are created. The management role still needs sts:AssumeRole permissions for any target cluster roles, which is the same in both models.
- Subject matching: IRSA conditions depend on the exact namespace and service account names, so a renamed service account silently breaks trust.
- Issuer lifecycle: IRSA depends on each cluster's OIDC issuer URL, which changes if a cluster is recreated.
- Session tags: Pod Identity sessions can carry tags from the association, which you can use in IAM conditions if your policy design needs them.
- Cross-account chaining: Both models still require the management role to be allowed to assume the cluster roles in target accounts.
- Audit trail: Pod Identity associations are visible as EKS resources, which helps when reviewing which service account maps to which role.
Ask your AWS account team or review the IAM and EKS documentation to confirm how session tags and trust conditions behave in your organization's policy guardrails.
The right choice depends on who runs the platform. IRSA is widely used and has long-standing tooling in infrastructure-as-code modules, but every management cluster adds an identity provider and a trust statement that the platform team must keep current. Pod Identity centralizes the binding in the EKS control plane and reduces trust policy edits, at the cost of one more managed add-on to install, upgrade and monitor. Neither option changes what Argo CD itself can do on target clusters, which is governed by the EKS access entries and the cluster role.
- Platform team skills: Choose the mechanism your team can troubleshoot during an incident, since token exchange failures look different in each model.
- Infrastructure as code: Check whether your Terraform or CloudFormation modules already manage IRSA roles or Pod Identity associations.
- Add-on lifecycle: The Pod Identity agent must be kept at a version compatible with your cluster, so include it in the upgrade plan.
- Mixed estates: Some organizations run IRSA on older clusters and Pod Identity on newer ones; document both paths in the runbook.
- Testing: Verify the chosen path on one non-production management cluster before rolling it to others.
Write down the owner of each trust statement or association so that cluster onboarding and offboarding stay with a named team.
A short design review can settle the choice. Start with the number of management clusters, the number of target accounts and how often clusters are created. Then check whether your organization already standardizes on one mechanism for workloads. Finally, confirm that the mechanism you pick is supported for your EKS version and Argo CD release, because the declarative setup guide describes how cluster secrets reference either approach but does not replace AWS documentation for the identity side.
- Cluster count: Many management clusters with frequent rebuilds favor a design where trust edits are rare or automated.
- Existing standards: Reuse what your security team has already reviewed for other workloads when possible.
- Rollback plan: Keep the previous trust statement or association in version control so a failed change can be reverted.
- Verification: Confirm the Argo CD controller can call
sts:AssumeRoleand list clusters with a test secret before onboarding production clusters. - Review ownership: Assign the trust policy and association changes to the same group that approves Argo CD cluster registrations.
Before you finalize the design, confirm the current Pod Identity prerequisites with the AWS documentation for your Region and EKS version.
How cross-account role chaining works across many clusters
The chain starts with the Argo CD service accounts. The application controller, ApplicationSet controller and server each run under a service account that is trusted by a single management role in the Argo CD hub account, either through IRSA or through the EKS Pod Identity agent. That management role is the only identity that holds AWS credentials. From there, it calls sts:AssumeRole on a role in each target account, and that cluster role is what EKS maps to Kubernetes access through an EKS access entry or, on older clusters, the deprecated aws-auth ConfigMap. Each hop is a separate, named role, so the path from a running pod to cluster-admin on a spoke can be read from IAM policy rather than reconstructed from kubeconfig files.
This design keeps the trust model auditable because the hub has one place where cross-account trust is granted. The management role's permissions policy lists the specific cluster role ARNs it may assume, and each spoke's cluster role trust policy names only the management role as its principal. Adding a cluster means adding one ARN to the list and one trust statement in the new account, and removing a cluster means removing both. Ask your team to confirm whether the spoke trust policies also restrict the source identity or session tags, since a broad principal such as an entire account root would widen the blast radius of the hub.
The cluster secret in Argo CD names the pieces that the chain depends on. In the awsAuthConfig block, clusterName identifies the EKS cluster, and roleARN identifies the cluster role to assume. The cluster's server URL and config fields must match the endpoint and region of that cluster. Errors here fail in predictable ways: a wrong roleARN or a missing sts:AssumeRole grant produces an access denied error from STS, a trust policy that does not name the management role fails the same way, and a missing access entry for the assumed role produces authorization errors from the Kubernetes API. Test each cluster with a read-only check after registration, and confirm the exact error messages with the Argo CD declarative setup guide for your version.
Mapping IAM roles, Kubernetes identities and cluster access
This table maps each IAM principal in an EKS registration to the Kubernetes identity it becomes, the Argo CD service account that assumes it, and the cluster secret field that points at it. Read each row left to right to confirm that every hop from Argo CD to the cluster has a documented owner. The main takeaway is that access entries are the path to use for new clusters, and that each mapping needs a named owner recorded alongside it.
| Identity hop | What it does | Where it is set | Ownership to record |
|---|---|---|---|
| Management role | IAM role that Argo CD assumes first, trusted by the controller, ApplicationSet and server service accounts | IRSA trust policy or EKS Pod Identity association on the management cluster | Platform team owner and the account that holds the role |
| Cluster role (per account) | IAM role in each target account that grants cluster access, granted sts:AssumeRole from the management role | Trust policy in the target account and the sts:AssumeRole permission on the management role | Owner of the target account or workload team |
| EKS access entry | Maps the cluster role to a Kubernetes identity and attaches an access policy such as AmazonEKSClusterAdminPolicy | EKS API on each target cluster, recorded as an access entry for the cluster role ARN | Cluster owner who approves the policy and its scope |
| Legacy aws-auth ConfigMap | Older mapping of IAM roles to Kubernetes users and groups in kube-system | aws-auth ConfigMap on the target cluster, deprecated in favor of access entries | Migration owner until the entry is removed |
| Argo CD service account | Kubernetes identity on the management cluster that holds the IRSA or Pod Identity link | Service account for the application controller, ApplicationSet controller and server | Platform team that maintains the Argo CD install |
| Cluster secret field | Points the registration at the role chain using awsAuthConfig or execProviderConfig with argocd-k8s-auth | Labeled cluster Secret in the Argo CD namespace, with the role ARN in the configuration | Team that registers the cluster and reviews changes in Git |
| Access policy scope | Defines what the mapped identity can do in the cluster, for example cluster-wide admin or narrower scope | Access entry policy association and any Kubernetes RBAC bound to the identity | Security reviewer who signs off on the scope |
Least-privilege controls for EKS access from Argo CD
Argo CD holds credentials that can reach every registered EKS cluster, so the controls that matter sit in three places: the IAM roles Argo CD assumes, the access entries and Kubernetes RBAC on each cluster, and the Argo CD projects and API access that decide who can use those registrations. The cards below cover each layer and the checks to run before a registration goes live.
Scope the management role to named cluster roles
The management role should hold sts:AssumeRole only on the specific cluster roles it must reach, not on a wildcard resource. Each registered account then needs its own trust path, so a compromised management role exposes only the clusters listed in its policy. Ask your team to list every cluster role in the policy and confirm that each one maps to a registered cluster.
Avoid cluster-admin in production
The declarative setup guide associates AmazonEKSClusterAdminPolicy, which grants cluster-admin. That is a convenient starting point for a lab but gives Argo CD unrestricted write access to every namespace and cluster-scoped object. In production, bind a narrower access policy or a custom Kubernetes role to the Argo CD cluster role, and confirm the exact permissions in a test cluster before rollout.
Restrict who can create cluster secrets
A cluster secret is the registration that tells Argo CD where a cluster is and how to authenticate to it. Anyone who can create or edit these secrets in the Argo CD namespace can point Argo CD at a new target. Limit write access to the namespace with Kubernetes RBAC, audit changes to secrets labeled for clusters, and keep registrations in version-controlled manifests reviewed by the platform team.
Combine access entries with Kubernetes RBAC
EKS access entries grant the Argo CD role entry to a cluster, but they do not limit what that role can change beyond the attached policy. Pair each access entry with a Kubernetes Role or ClusterRole that names the resource kinds and namespaces Argo CD may write. Check that the aws-auth ConfigMap no longer grants the same identity extra access, because the deprecated path can silently widen what a role can do.
Bind AppProjects to destination clusters
Argo CD AppProjects decide which destination clusters and namespaces each application may target. An EKS registration without a matching project restriction lets any application that can see that cluster deploy to it. Set the destination list in each AppProject to the exact cluster names and namespaces the owning team uses, and keep the default project locked down so no application falls outside a scoped project.
Limit the server to required namespaces
The Argo CD server handles the UI and API, so its service account and any cluster roles it holds should reach only the namespaces it needs. Where teams run their own Argo CD instances, a namespace-scoped install keeps the server out of cluster-wide resources. Check which namespaces the server can read and write, and confirm that cluster-scoped permissions come only from the controller roles that require them.
Protect API access and credential redaction
Argo CD authenticates API requests only with JSON Web Tokens and redacts cluster, Git and OAuth2 credentials from API responses and logs. Those protections keep registration details out of casual view, but they do not stop a user with valid tokens from triggering syncs against a cluster. Confirm that tokens are short-lived where your SSO setup allows it, and that the admin account is disabled once SSO users are in place.
Why EKS cluster registration fails and how to fix it
This table lists the failures teams most often hit when registering an EKS cluster in Argo CD, with the likely cause and fix for each. Use it as a first-pass triage list, then check the exact behavior against the current Argo CD and AWS documentation for your versions.
| Symptom | Likely cause | Fix to try |
|---|---|---|
| AccessDenied on sts:AssumeRole | The management role trust policy does not trust the controller, ApplicationSet controller or server service account, or the caller lacks permission to assume the target cluster role | Check the trust policy on the management role and the sts:AssumeRole grant on each cluster role, then confirm the pod identity is the one you configured |
| Cluster is unreachable with no access error | No EKS access entry maps the cluster role to Kubernetes permissions, so the token is valid but authorization fails | Create an access entry for the role and associate an access policy scoped to what Argo CD needs, or confirm the deprecated aws-auth ConfigMap is the mechanism your cluster uses |
| argocd-k8s-auth not found in the container | The exec provider binary is missing from the image used by the controller or server, or the path in execProviderConfig does not match where it is installed | Use an Argo CD image that includes the helper, or confirm the binary location and PATH in the running pod before changing the cluster secret |
| Cluster connects to the wrong cluster or fails to authenticate | The cluster name or region in the cluster secret does not match the EKS cluster, so the token is generated for a different endpoint or scope | Compare the name and region values in the secret with the output of your AWS CLI describe command, and correct the server URL to match the cluster endpoint |
| Token rejected after IRSA setup | The IRSA trust policy references the wrong OIDC provider, namespace or service account name, so the web identity exchange fails | Confirm the OIDC provider ARN, the namespace and the service account subject in the trust policy match the deployed service accounts exactly |
| No credentials on a service account using Pod Identity | No Pod Identity association links the management role to the controller, ApplicationSet controller or server service account in the Argo CD namespace | Create a Pod Identity association for each service account that calls AWS, and confirm the Pod Identity agent is running on the nodes |
How to test cluster registration before onboarding teams
Test the registration in a fixed order before any team sees it, because each step depends on the one before. Start with the identity: exec into the application controller pod, or read its service account annotations, and confirm that the management role is the identity in use. If the pod resolves to the node role or to no AWS identity at all, the IRSA or EKS Pod Identity setup is wrong and nothing downstream will work. Next, assume each cluster role from that identity with the AWS CLI, which confirms that the sts:AssumeRole grant exists for every target account. Then check cluster access itself: with the role assumed, run kubectl auth can-i --list against the cluster, and confirm the EKS access entry carries the policy you intended, such as AmazonEKSClusterAdminPolicy in the guide's example, which is full cluster-admin.
Next, prove that Argo CD itself can use the registered secret. List cluster resources through the Argo CD API or argocd cluster get and confirm the connection status is successful and the server version reads correctly. Then deploy a small test application to a non-production namespace, using a dedicated test repository and a throwaway AppProject. Watch it sync, then delete it and confirm the resources are removed. Finally, test the boundary. Point a test application at a namespace or cluster that its project does not allow and confirm Argo CD rejects it. An AppProject that permits every destination is the most common reason a registration appears to work while still exposing other clusters. Record the outputs of each step so a later run has something to compare against.
Repeat this full sequence after every Argo CD upgrade and after any change to access entries, role trust policies or the cluster's authentication mode. An upgrade can change how the exec provider is invoked or how credentials are cached, and an access entry edit can silently drop a policy. Confirm the current upgrade notes for your target version before running the checks, since the Argo CD 2.14 to 3.0 upgrade notes cover RBAC and resource tracking changes that affect what a test should expect. Ask your platform owner to keep the test application and the recorded outputs under version control, so the sequence can be rerun by someone other than the original author.
Questions teams ask before registering EKS clusters
How much does it cost to register EKS clusters in Argo CD?
No fixed figure can be given from the supplied research, and DeployOpen does not publish prices. Cost follows from the written scope, which is driven by the number of AWS accounts, the number of clusters, how many IAM roles and access entries must be designed and reviewed, and how much testing each cluster needs. Most of the cost is one-time design and build work, with a smaller recurring cost when new clusters or accounts are added. Ask any partner for a quote that separates the account and IAM design, the per-cluster registration work, the verification steps and any ongoing support.
How long does EKS cluster registration take?
Duration depends on the same drivers as cost: how many accounts and clusters are in scope, how quickly IAM approvals come back, and whether cluster owners agree on access entries. A single account with a few clusters usually moves faster than a multi-account estate where each cross-account role needs review. Confirm the timeline with the partner in the written scope, and ask which steps depend on your approvals so you can plan the calendar around them.
What do we need to provide for the engagement?
The work needs access to the AWS accounts that host Argo CD and the target clusters, plus someone who can approve IAM roles and trust policies. Cluster owners must confirm which Kubernetes access they will grant and to which namespaces. You should also provide a list of accounts and cluster names, the Argo CD installation details, and the team that will own the resulting configuration after handover. Confirm the exact access level required in your environment before the scope is signed.
Can our internal platform team register EKS clusters alone?
Yes, a team with AWS IAM and Kubernetes experience can do this without a partner, and the Argo CD documentation describes the steps. The usual risk is the design rather than the commands: a management role that is broader than needed, or an access entry that grants cluster-admin where a narrower policy would do. A partner is most useful when the design needs independent review, when many accounts must be handled consistently, or when the internal team lacks time for testing and handover. Decide based on your capacity and the review you need.
Should we use IRSA or EKS Pod Identity for the management role?
Both options let the Argo CD controller, ApplicationSet controller and server service accounts receive AWS credentials without static keys, and the declarative setup guide covers both. IRSA relies on the cluster's OIDC provider and annotated service accounts, while EKS Pod Identity uses the Pod Identity agent. Choose based on what your platform team already operates and what your AWS governance allows. Confirm which option your organization standardizes on before writing the trust policies.
How do we keep cross-account access least privilege?
The management role needs permission to assume a role in each target account, and each target role then needs access to its own cluster. Scope the sts:AssumeRole permission to the specific cluster roles rather than a wildcard. On the cluster side, use an EKS access entry with the narrowest access policy that meets the use case. The guide's example associates AmazonEKSClusterAdminPolicy, which grants cluster-admin, so treat it as a starting point to replace, not a default to keep. Review each policy with your security team before rollout.
What breaks most often when registering EKS clusters?
The most common failures are trust policies that do not match the service account or Pod Identity association, roles that can be assumed but have no EKS access entry, and kubeconfig-style exec settings that reference a helper binary or role the controller cannot reach. Test each cluster with a read-only application before granting write access, and confirm that the aws-auth ConfigMap is not still controlling access where access entries are expected. Check the Argo CD declarative setup guide for the exact keys your version expects.
How DeployOpen scopes and delivers EKS registration work
DeployOpen is a Chainscore Labs company that plans, implements, hardens and documents self-hosted open-source platforms in your own AWS accounts. The cards below show how an EKS registration engagement is scoped in writing and which deliverables connect the management role, the cluster secrets and the access evidence your team keeps.
Scope agreed in writing
Most engagements are fixed-scope, so the cluster list, account structure, identity model and deliverables are agreed in writing before any work starts. For EKS registration, the scope should name each AWS account, each target cluster, whether the team uses IRSA or EKS Pod Identity on the management cluster, and who approves the role trust policies. Ask for the scope to list what is excluded, such as cluster provisioning or Argo CD upgrades.
Management role and trust design
The management role is the identity the Argo CD application controller, ApplicationSet controller and server use to reach each cluster. Its trust relationship depends on whether the management cluster uses IRSA or the EKS Pod Identity agent. DeployOpen designs the role, the sts:AssumeRole grants to each cluster role, and the trust conditions, then documents them so your security team can review each path.
Cluster secrets and exec configuration
Each EKS cluster is registered as a declarative Secret that uses either awsAuthConfig or execProviderConfig with argocd-k8s-auth, so no static kubeconfig is stored. DeployOpen writes these Secrets, labels them for the right projects, and confirms the cluster server URLs and role ARNs match your inventory. Check that no bearer tokens or kubeconfig files are committed to Git during review.
Access entries and least-privilege policies
Cluster access is granted through EKS access entries, and the aws-auth ConfigMap is deprecated for this purpose. The reference example associates AmazonEKSClusterAdminPolicy, which grants cluster-admin, so a production engagement should replace it with narrower policies and scoped access. DeployOpen maps each access entry to a documented permission set and records which principals hold which rights on each cluster.
Test evidence and handover
Deliverables include a test record showing that each registered cluster syncs an application, that a denied action fails, and that the management role cannot reach clusters outside its list. Your team receives role designs, Secret templates, policy documents and the test results in your repositories. Ask for the evidence format and the acceptance criteria before the scope is signed.
Ongoing support as a retainer
Ongoing support, upgrades and continuous testing are available as retainers. Typical follow-up work includes adding clusters, rotating role trust settings after an Argo CD upgrade, and rerunning access tests after EKS version changes. Ask for the retainer scope in writing, including who responds to access-entry changes and how new clusters are onboarded through the same review path.
