Profile Applicability:
 • Level 1

Description:
 Kubernetes workloads should not use cluster node service accounts to authenticate to Amazon EKS APIs. Each Kubernetes workload that needs to authenticate to other AWS services using AWS IAM should be provisioned with a dedicated Service account.

Rationale:
 Manual approaches for authenticating Kubernetes workloads running on Amazon EKS against AWS APIs can lead to security risks, such as storing service account keys as a Kubernetes secret (which introduces manual key rotation and potential for key compromise) or using the underlying node's IAM service account (which violates the principle of least privilege in a multi-tenanted environment). By using dedicated service accounts, the Kubernetes workloads can be granted only the necessary permissions they need.

Impact:
 This approach helps to reduce the risk of unauthorized access to AWS services and ensures that each pod has only the minimal required permissions to interact with AWS APIs.

Default Value:

  • Review the service accounts used in each namespace.

  • Ensure that service accounts are not using the node’s IAM role.

  • Verify that the automountServiceAccountToken: false setting is in place for each default service account.

  • Ensure that only the minimum permissions are granted to the IAM role associated with the service account, and that they follow the principle of least privilege.

Remediation

Test Plan:

Using AWS Console:

  1. Go to the Amazon EKS Console and check if IAM roles for service accounts are enabled for your clusters.

  2. Review each service account in use by the pods to ensure they have the necessary IAM roles and permissions associated.

Using AWS CLI:
To list the IAM roles for service accounts:

aws eks describe-cluster --name <cluster-name> --query "cluster.identity" --region <region>


Implementation Plan

Using AWS Console:

  1. Enable IAM roles for service accounts on your EKS cluster.

  2. Assign an IAM role to each Kubernetes service account that needs access to AWS services.

  • Example using eksctl:

eksctl create iamserviceaccount --region <region> --name <service-account-name> --namespace <namespace> --cluster <cluster-name> --attach-policy-arn arn:aws:iam::<account-id>:policy/<policy-name> --approve

Using AWS CLI:

  1. Create IAM service accounts and associate them with appropriate IAM roles.

  2. Use the following command to create the service account with the necessary IAM role:

    • eksctl create iamserviceaccount --region <region> --name <service-account-name> --namespace <namespace> --cluster <cluster-name> --attach-policy-arn arn:aws:iam::<account-id>:policy/<policy-name> --approve


Backout Plan

Using AWS Console

  1. Rollback IAM Role Configuration: If issues arise, revert the IAM role bindings or remove the IAM roles associated with the service accounts and revert to using the node IAM role.

  2. Revert Service Account Changes: If the new service accounts do not work as expected, remove the association with IAM roles and reconfigure the service accounts to use the default node IAM role temporarily.

Using AWS CLI:

  1. To remove the IAM role from the service account:
eksctl delete iamserviceaccount --region <region> --name <service-account-name> --namespace <namespace> --cluster <cluster-name>


References:

  1. IAM Roles for Service Accounts (IRSA) - Amazon EKS Documentation

  2. Walkthrough: Updating a DaemonSet to use IAM for Service Accounts

  3. Best Practices for Managing Service Account Permissions in Amazon EKS