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.

Security considerations for EKS Capabilities

This topic covers important security considerations for EKS Capabilities, including IAM role configuration, Kubernetes permissions, and architectural patterns for multi-cluster deployments and cross-account AWS resource management.

EKS Capabilities use a combination of IAM roles, EKS access entries, and Kubernetes RBAC to provide secure access to AWS services, in-cluster Kubernetes resources, and integrations with AWS CodeConnections, AWS Secrets Manager, and other AWS services.

Capability IAM role

When you create a capability, you provide an IAM capability role that EKS uses to perform actions on your behalf. This role must:

It is a best practice to consider the scope of privileges required for your specific use case and grant only those permissions necessary to meet your requirements. For example, when using the EKS Capability for Kube Resource Orchestrator, no IAM permissions may be required, while when using the EKS Capability for AWS Controllers for Kubernetes you may grant full access to one or more AWS services.

For detailed information about creating and configuring capability IAM roles, see Amazon EKS capability IAM role.

EKS access entries

When you create a capability with an IAM role, Amazon EKS automatically creates an access entry for that role on your cluster. This access entry grants the capability baseline Kubernetes permissions to function.

The access entry includes:

Default access entry policies by capability

Each capability type grants the capability role the required permissions, setting different default access entry policies as follows:

See Review access policy permissions for more detailed information.

Additional Kubernetes permissions

Some capabilities may require additional Kubernetes permissions beyond the default access entry policies. You can grant these permissions using either:

ACK secret reader permissions

Some ACK controllers need to read Kubernetes secrets to retrieve sensitive data like database passwords. The following ACK controllers require secret read access:

To grant secret read permissions:

kro arbitrary resource permissions

kro requires permissions to create and manage the resources defined in your ResourceGraphDefinitions. By default, kro can only watch and manage RGDs themselves.

To grant kro permissions to create resources:

Option 1: Access entry policies

Associate pre-defined access entry policies like AmazonEKSAdminPolicy or AmazonEKSEditPolicy to the capability’s access entry.

Option 2: Kubernetes RBAC

Create a ClusterRoleBinding that grants the capability’s Kubernetes user the necessary permissions:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: kro-cluster-admin
subjects:
- kind: User
  name: arn:aws:sts::111122223333:assumed-role/my-kro-role/kro
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: cluster-admin
  apiGroup: rbac.authorization.k8s.io

IAM permissions required by capability

Security best practices

IAM least privilege

Grant your capability resources only the permissions required for your use case. This does not mean you cannot grant broad administrative permissions to your capabilities if required. In such cases, you should govern access to those resources appropriately.

Capability roles:

Example: Instead of "Resource": "*", specify patterns for specific resources or groups of resources.

"Resource": [
  "arn:aws:s3:::my-app-*",
  "arn:aws:rds:us-west-2:111122223333:db:prod-*"
]

Use IAM condition keys to further restrict access:

"Condition": {
  "StringEquals": {
    "aws:ResourceTag/Environment": "production"
  }
}

For additional IAM configuration information, see the considerations section for each capability.

Namespace isolation for Argo CD secrets

The managed Argo CD capability has access to all Kubernetes secrets within its configured namespace (default: argocd). To maintain optimal security posture, follow these namespace isolation practices:

This isolation ensures that Argo CD’s secret access is limited to only the credentials it needs for Git repository authentication and other Argo CD-specific operations.

Kubernetes RBAC

Control which users and service accounts can create and manage capability resources. It is a best practice to deploy capability resources in dedicated namespaces with appropriate RBAC policies.

Example: RBAC Role to work with ACK, allowing for S3 Bucket resource management in the app-team namespace:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: ack-s3-manager
  namespace: app-team
rules:
- apiGroups: ["s3.services.k8s.aws"]
  resources: ["buckets"]
  verbs: ["get", "list", "create", "update", "delete"]

Audit logging

CloudTrail: All EKS Capability API operations (create, update, delete) are logged to AWS CloudTrail.

Enable CloudTrail logging to track:

Network access and VPC endpoints

Private Argo CD API access

You can restrict access to the Argo CD API server by associating one or more VPC endpoints with the hosted Argo CD endpoint. This enables private connectivity to the Argo CD UI and API from within your VPC without traversing the public internet.

Deploying to private clusters

The Argo CD capability can deploy applications to fully private EKS clusters, providing a significant operational benefit by eliminating the need for VPC peering or complex networking configurations. However, when designing this architecture, consider that Argo CD will pull configuration from Git repositories (which may be public) and apply it to your private clusters.

Ensure you:

Compliance

EKS Capabilities are fully managed and have the compliance certifications of Amazon EKS.

For current compliance information, see AWS Services in Scope by Compliance Program.

Next steps