AWS eks medium security documentation change
Summary
Enhanced documentation for Argo CD permissions model, clarifying global vs project-scoped roles, added requirements for sourceNamespaces, and expanded project role configuration details.
Security assessment
The changes explicitly define a two-level permission model (global vs project scopes) and emphasize that EDITOR/VIEWER users cannot access applications without project roles. This addresses potential over-privilege risks by documenting least-privilege requirements. Added warnings about sourceNamespaces configuration prevent deployment failures that could cause security misconfigurations.
Diff
diff --git a/eks/latest/userguide/argocd-permissions.md b/eks/latest/userguide/argocd-permissions.md index a35c78830..55ccfa273 100644 --- a//eks/latest/userguide/argocd-permissions.md +++ b//eks/latest/userguide/argocd-permissions.md @@ -5 +5 @@ -How permissions work with Argo CDBuilt-in RBAC rolesConfigure role mappingsAdmin account usageProject-based access controlCommon permission patternsBest practicesAWS service permissionsNext steps +How permissions work with Argo CDBuilt-in RBAC rolesProject roles and project-scoped accessConfigure role mappingsAdmin account usageProject-based access controlCommon permission patternsBest practicesAWS service permissionsNext steps @@ -34 +34,5 @@ When a user accesses Argo CD: -The Argo CD capability provides three built-in roles that you map to AWS Identity Center users and groups. +The Argo CD capability provides three built-in roles that you map to AWS Identity Center users and groups. These are **globally scoped roles** that control access to Argo CD resources like projects, clusters, and repositories. + +###### Important + +Global roles control access to Argo CD itself, not to project-scoped resources like Applications. EDITOR and VIEWER users cannot see or manage Applications by default—they need project roles to access project-scoped resources. See Project roles and project-scoped access for details on granting access to Applications and other project-scoped resources. @@ -38 +42 @@ The Argo CD capability provides three built-in roles that you map to AWS Identit -Full access to all applications and settings: +Full access to all Argo CD resources and settings: @@ -40 +44 @@ Full access to all applications and settings: - * Create, update, and delete applications and ApplicationSets + * Create, update, and delete Applications and ApplicationSets in any project @@ -48 +52 @@ Full access to all applications and settings: - * Manage projects + * Create and manage projects @@ -59 +63 @@ Full access to all applications and settings: -Can create and modify applications but cannot change Argo CD settings: +Can update projects and configure project roles, but cannot change global Argo CD settings: @@ -61 +65 @@ Can create and modify applications but cannot change Argo CD settings: - * Create and update applications and ApplicationSets + * Update existing projects (cannot create or delete projects) @@ -63,3 +67 @@ Can create and modify applications but cannot change Argo CD settings: - * Sync and refresh applications - - * View application status and history + * Configure project roles and permissions @@ -69 +71 @@ Can create and modify applications but cannot change Argo CD settings: - * Cannot delete applications + * Cannot change global Argo CD configuration @@ -71 +73 @@ Can create and modify applications but cannot change Argo CD settings: - * Cannot change Argo CD configuration + * Cannot manage clusters or repositories directly @@ -73 +75 @@ Can create and modify applications but cannot change Argo CD settings: - * Cannot manage clusters or repositories + * Cannot see or manage Applications without project roles @@ -80,3 +82 @@ Can create and modify applications but cannot change Argo CD settings: -Read-only access to applications: - - * View application status and history +Read-only access to Argo CD resources: @@ -84 +84 @@ Read-only access to applications: - * View application manifests and resources + * View project configurations @@ -92 +92 @@ Read-only access to applications: - * Cannot sync or refresh applications + * Cannot see or manage Applications without project roles @@ -99 +99,47 @@ Read-only access to applications: -The VIEWER role provides limited visibility: users can see all projects but cannot list clusters or repositories. To grant access to specific applications, assign users to project-specific roles in addition to the global VIEWER role. +To grant EDITOR or VIEWER users access to Applications, an ADMIN or EDITOR must create project roles that map Identity Center groups to specific permissions within a project. + +## Project roles and project-scoped access + +Global roles (ADMIN, EDITOR, VIEWER) control access to Argo CD itself. Project roles control access to resources and capabilities within a specific project, including: + + * **Resources** : Applications, ApplicationSets, repository credentials, cluster credentials + + * **Capabilities** : Log access, exec access to application pods + + + + +**Understanding the two-level permission model** : + + * **Global scope** : Built-in roles determine what users can do with projects, clusters, repositories, and Argo CD settings + + * **Project scope** : Project roles determine what users can do with resources and capabilities within a specific project + + + + +This means: + + * ADMIN users can access all project resources and capabilities without additional configuration + + * EDITOR and VIEWER users must be granted project roles to access project resources and capabilities + + * EDITOR users can create project roles to grant themselves and others access within projects they can update + + + + +**Example workflow** : + + 1. An ADMIN maps an Identity Center group to the EDITOR role globally + + 2. An ADMIN creates a project for a team + + 3. The EDITOR configures project roles within that project to grant team members access to project-scoped resources + + 4. Team members (who may have VIEWER global role) can now see and manage Applications in that project based on their project role permissions + + + + +For details on configuring project roles, see Project-based access control. @@ -127,6 +173,6 @@ EKS Capabilities integration with AWS Identity Center supports up to 1,000 ident - aws eksfe update-capability \ - --region <replaceable>us-east-1</replaceable> \ - --cluster-name <replaceable>cluster</replaceable> \ - --capability-name <replaceable>capname</replaceable> \ - --endpoint "https://eks.<replaceable>ap-northeast-2</replaceable>.amazonaws.com" \ - --role-arn "arn:aws:iam::[.replaceable]<literal>111122223333</literal>:role/[.replaceable]`EKSCapabilityRole`" \ + aws eks update-capability \ + --region us-east-1 \ + --cluster-name cluster \ + --capability-name capname \ + --endpoint "https://eks.ap-northeast-2.amazonaws.com" \ + --role-arn "arn:aws:iam::[.replaceable]111122223333:role/[.replaceable]`EKSCapabilityRole`" \ @@ -251,0 +298,4 @@ Projects provide: +### Source namespaces + +When using the EKS Argo CD capability, the `spec.sourceNamespaces` field is required in AppProject definitions. This field specifies which namespace can contain Applications or ApplicationSets that reference this project. + @@ -254 +304,31 @@ Projects provide: -The managed capability requires AppProject resources to specify `.spec.sourceNamespaces` to define which namespaces the project can watch for Applications. Typically, this should be set to the namespace you specified when creating the capability (usually `argocd`). +The EKS Argo CD capability only supports a single namespace for Applications and ApplicationSets—the namespace you specified when creating the capability (typically `argocd`). This differs from open source Argo CD which supports multiple namespaces. + +**AppProject configuration** + +All AppProjects must include the capability’s configured namespace in `sourceNamespaces`: + + + apiVersion: argoproj.io/v1alpha1 + kind: AppProject + metadata: + name: team-a-project + namespace: argocd + spec: + description: Applications for Team A + + # Required: Specify the capability's configured namespace (configuration.argoCd.namespace) + sourceNamespaces: + - argocd # Must match your capability's namespace configuration + + # Source repositories this project can deploy from + sourceRepos: + - 'https://github.com/my-org/team-a-*' + + # Destination restrictions + destinations: + - namespace: 'team-a-*' + server: arn:aws:eks:us-west-2:111122223333:cluster/my-cluster + +###### Note + +If you omit the capability’s namespace from `sourceNamespaces`, Applications or ApplicationSets in that namespace cannot reference this project, resulting in deployment failures. @@ -258 +338,5 @@ The managed capability requires AppProject resources to specify `.spec.sourceNam -Users with EDITOR or VIEWER roles can be restricted to specific projects. ADMIN users have access to all projects. +Project roles grant EDITOR and VIEWER users access to project resources (Applications, ApplicationSets, repository and cluster credentials) and capabilities (logs, exec). Without project roles, these users cannot access these resources even if they have global role access. + +ADMIN users have access to all Applications without needing project roles. + +**Example: Granting Application access to team members** @@ -264,0 +349 @@ Users with EDITOR or VIEWER roles can be restricted to specific projects. ADMIN + namespace: argocd @@ -271 +356 @@ Users with EDITOR or VIEWER roles can be restricted to specific projects. ADMIN - # Map Identity Center groups or users to project roles + # Project roles grant Application-level access @@ -274 +359 @@ Users with EDITOR or VIEWER roles can be restricted to specific projects. ADMIN - description: Team A developers + description: Team A developers - can manage Applications @@ -281 +366 @@ Users with EDITOR or VIEWER roles can be restricted to specific projects. ADMIN - description: Team A viewers + description: Team A viewers - read-only Application access @@ -286 +371,36 @@ Users with EDITOR or VIEWER roles can be restricted to specific projects. ADMIN - - 886303e0-f051-7068-b225-e6392b959da0 # Identity Center user ID also works + +**Understanding project role policies** : + +The policy format is: `p, proj:<project>:<role>, <resource>, <action>, <object>, <allow/deny>` + +**Resource policies** : + + * `applications, **, team-a/** , allow` \- Full access to all Applications in the team-a project + + * `applications, get, team-a/*, allow` \- Read-only access to Applications + + * `applications, sync, team-a/*, allow` \- Can sync Applications but not create/delete + + * `applications, delete, team-a/*, allow` \- Can delete Applications (use with caution) + + * `applicationsets, **, team-a/** , allow` \- Full access to ApplicationSets + + * `repositories, *, *, allow` \- Access to repository credentials + + * `clusters, *, *, allow` \- Access to cluster credentials + + + + +**Capability policies** : +