Jump to content

Simplifying IAM Permissions for Amazon EKS Addons with EKS Pod Identity

Amazon Web Services
Amazon Web Services
in Amazon Web Services (AWS)

Featured Replies

Posted

This blog was authored by Sriram Ranganathan, Senior Product Manager, AWS and Vikram Venkataram, Principal Solutions Architect, AWS. 

Introduction

As part of AWS re:Invent 2023, Amazon Elastic Kubernetes Service (Amazon EKS) launched Amazon EKS Pod Identity, simplifying how you apply AWS Identity and Access Management (IAM) permissions to your Kubernetes cluster workloads. Some EKS add-ons, which enable critical cluster functionality like networking, storage, and compute, need to interact with underlying AWS services. EKS Pod Identities helps inject IAM permissions to EKS add-ons, enabling add-ons to interact with underlying AWS services.

EKS add-on containers leverage AWS SDKs to make API requests to AWS services using IAM permissions. Add-ons must sign their AWS API requests with AWS credentials. Each EKS Pod Identity association links a role to a service account in a specific cluster namespace. EKS add-ons leverage Kubernetes service accounts to receive IAM permissions. When an add-on pod uses a service account with an association, EKS sets environment variables in the pod’s containers. These variables configure AWS SDKs to use EKS Pod Identity credentials when interacting with AWS services.

You can now supply EKS Pod Identity associations for add-ons directly through EKS in a single operation, eliminating the need to manage add-ons and Pod Identities separately. This feature allows you to specify EKS Pod Identity permissions for add-ons during initial cluster creation, simplifying the process of setting up access controls for cluster components. This approach makes it easier for you to apply permissions to EKS add-ons. For supported add-ons, see the EKS user guide.

Feature Overview

EKS add-ons API has introduced a new podIdentityAssociations parameter, enabling you to implement more granular IAM role to service account mappings. This feature enables add-ons to associate multiple service accounts, each with precisely defined IAM permissions. By leveraging this feature, customers can implement the principle of least privilege, so that each service account receives only the minimum required permissions necessary for its specific operational requirements.

The podIdentityAssociations parameter is accessible through both the AWS Command Line Interface (AWS CLI) commands aws eks create-addon and aws eks update-addon, providing a streamlined method to configure service account permissions during add-on management.

Example create add-on workflow

To demonstrate the practical application of the new podIdentityAssociations parameter, consider a scenario involving an existing EKS cluster running Kubernetes version 1.30. When adding the Amazon VPC CNI (vpc-cni) add-on to the cluster using the CLI, customers need to associate specific IAM roles with the add-on’s service account.

Determining the appropriate IAM permissions for an add-on is the first step. Customers can leverage two key Amazon EKS API operations to identify the necessary permissions and service account configurations:

  • DescribeAddonVersions API: This operation provides information about available add-on versions and if the add-on needs IAM permissions.
  • DescribeAddonConfiguration API: This API helps customers understand the specific service account and associated permission needs for the add-on.

By combining these API calls, you can precisely map the IAM permissions to the correct service account for optimal configuration and minimal privilege access for your EKS add-ons.

The first step utilizes the describe-addon-versions CLI command to retrieve the default vpc-cni version for Kubernetes 1.30 from the Amazon EKS API. By inspecting the requiresIamPermissions parameter, you can quickly identify whether the selected add-on necessitates IAM permissions.

aws eks describe-addon-versions \
   --addon-name vpc-cni \
   --kubernetes-version 1.30 \
   --query 'addons[].{
     AddonName: addonName,
     Versions: addonVersions[?compatibilities[].defaultVersion|contains(@, `true`)].{
       AddonVersion: addonVersion,
       KubernetesVersion: compatibilities[0].clusterVersion,
       RequiresIamPermissions: requiresIamPermissions
     }
   }' \

The output is as below:

————————————————————————-
|                         DescribeAddonVersions                         |
+———————————————————————–+
|                               AddonName                               |
+———————————————————————–+
|  vpc-cni                                                              |
+———————————————————————–+
||                              Versions                               ||
|+——————–+———————+————————–+|
||    AddonVersion    |  KubernetesVersion  | RequiresIamPermissions   ||
|+——————–+———————+————————–+|
||  v1.19.0-eksbuild.1|  1.30               |  True                    ||
|+——————–+———————+————————–+|

Notice that the requiresIamPermissions flag is set to True, indicating that the add-on’s service account needs specific IAM permissions. To determine the service account and its required permissions, customers can leverage the DescribeAddonConfiguration API.

aws eks describe-addon-configuration \
  --addon-name vpc-cni \
  --addon-version v1.19.0-eksbuild.1 \
  --query '{
    addonName: addonName,
    addonVersion: addonVersion,
    podIdentityConfiguration: podIdentityConfiguration
  }' \
  --output json | jq '.'

This API call returns the specific IAM permissions recommended for the add-on’s service account.

{
  "addonName": "vpc-cni",
  "addonVersion": "v1.19.0-eksbuild.1",
  "podIdentityConfiguration": [
    {
      "serviceAccount": "aws-node",
      "recommendedManagedPolicies": [
        "arn:aws:iam::aws:policy/AmazonEKS_CNI_Policy"
      ]
    }
  ]
}

From the output above, vpc-cni add-on needs permissions defined in the AmazonEKS_CNI_Policy AWS managed policy, which should be applied to the aws-node service account. For this walkthrough, an IAM role AmazonEKSPodIdentityAmazonVPCCNIRole with the recommended permissions has already been created based on EKS Pod Identity specification. To view the trust policy and the AWS managed policies attached to the role, use the below commands.

aws iam list-attached-role-policies \
  --role-name AmazonEKSPodIdentityAmazonVPCCNIRole \
  --query 'AttachedPolicies[].PolicyArn' \
  --output json
  
[
    "arn:aws:iam::aws:policy/AmazonEKS_CNI_Policy"
]


aws iam get-role \
  --role-name AmazonEKSPodIdentityAmazonVPCCNIRole \
  --query 'Role.AssumeRolePolicyDocument' \
  --output json | jq '.'
  

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "pods.eks.amazonaws.com"
      },
      "Action": [
        "sts:AssumeRole",
        "sts:TagSession"
      ]
    }
  ]
}


aws iam get-role \
  --role-name AmazonEKSPodIdentityAmazonVPCCNIRole \
  --query 'Role.Arn' \                       
  --output json | jq '.'
  
"arn:aws:iam::123456789012:role/AmazonEKSPodIdentityAmazonVPCCNIRole"

Now that we know the permissions required by the vpc-cni add-on and the service account to which these permissions should be applied, you can create the add-on by passing the podIdentityAssociations parameter, which maps the previously created role to the aws-node service account of the vpc-cni add-on.

aws eks create-addon \
  --cluster-name demo \
  --addon-name vpc-cni \
  --addon-version v1.19.0-eksbuild.1 \
  --pod-identity-associations '[{
    "serviceAccount": "aws-node",
    "roleArn": "arn:aws:iam::123456789012:role/AmazonEKSPodIdentityAmazonVPCCNIRole"
  }]'
  

{
    "addon": {
        "addonName": "vpc-cni",
        "clusterName": "demo",
        "status": "CREATING",
        "addonVersion": "v1.19.0-eksbuild.1",
        "health": {
            "issues": []
        },
        "addonArn": "arn:aws:eks:us-east-2:123456789012:addon/demo/vpc-cni/e0c9a2b7-0df2-5ab5-60ee-6871ee9237a5",
        "createdAt": "2024-11-19T17:17:44.916000+00:00",
        "modifiedAt": "2024-11-19T17:17:44.936000+00:00",
        "tags": {},
        "podIdentityAssociations": [
            "arn:aws:eks:us-east-2:123456789012:podidentityassociation/demo/a-5ygeq7y6kw0aw8lmk"
        ]
    }
}

Once the add-on is installed, you can verify that all pods are up and running and that the add-on received the IAM permissions. To confirm the credentials, look for the AWS_CONTAINER_CREDENTIALS_FULL_URI and AWS_CONTAINER_AUTHORIZATION_TOKEN_FILE environment variables. To learn more about the credential mechanism with EKS Pod Identity, you can check out this blog.

kubectl get pods -n kube-system -l k8s-app=aws-node
NAME             READY   STATUS    RESTARTS   AGE
aws-node-q5jjb   2/2     Running   0          6m19s
aws-node-x5ks6   2/2     Running   0          6m19s

Let’s do a describe on the pod object:

kubectl describe pods -n kube-system -l k8s-app=aws-node
Name:                 aws-node-q5jjb
Namespace:            kube-system
Labels:               app.kubernetes.io/instance=aws-vpc-cni
                      app.kubernetes.io/name=aws-node
                      controller-revision-hash=7995674748
                      k8s-app=aws-node
                      pod-template-generation=1
...
Init Containers:
...
    Environment:
      ...
      AWS_CONTAINER_CREDENTIALS_FULL_URI:      http://169.254.170.23/v1/credentials
      AWS_CONTAINER_AUTHORIZATION_TOKEN_FILE:  /var/run/secrets/pods.eks.amazonaws.com/serviceaccount/eks-pod-identity-token
    Mounts:
      /host/opt/cni/bin from cni-bin-dir (rw)
      /var/run/secrets/kubernetes.io/serviceaccount from kube-api-access-whv85 (ro)
      /var/run/secrets/pods.eks.amazonaws.com/serviceaccount from eks-pod-identity-token (ro)
      
...

Pod identity associations can be applied to add-ons anytime. If you have already created the vpc-cni add-on without the recommended IAM permissions, you can always apply these permissions after the add-on is created using the update-addon CLI command.

Example cluster creation workflow using EKS console

IAM Role for Service Accounts (IRSA) lets you associate an IAM role with a Kubernetes service account. This helps you to implement the principle of least privilege by giving pods only the permissions they need. Setting up IRSA required you to first create the EKS cluster, then extract its unique OpenID Connect (OIDC) provider URL. This URL was required for creating an OIDC provider, which would generate a specific Amazon Resource Name (ARN) necessary for configuring the IAM role’s trust policy. This sequential workflow meant that IAM credentials for add-ons could only be applied after the cluster was created.

EKS Pod Identity represents a significant improvement in this workflow. By removing the OIDC provider dependency, the solution allows for more direct IAM permission assignment. You can now apply IAM permissions to service accounts of add-ons as part of the cluster creation workflow. You no longer need to wait for the cluster to be created before applying permissions needed by the add-on. This streamlined approach simplifies the process of configuring add-on access and enhances the overall efficiency and security of cluster deployment.

Let’s see this in action. You can now select the add-ons you need as part of cluster creation and easily apply existing IAM roles.

Figure 1: Selected EKS add-ons in the console

Figure 1: Selected EKS add-ons in the console

After selecting the add-ons and navigating to the Configure selection add-ons settings page, you will see the Add-on access section for any add-on that requires IAM permissions. You can select available IAM roles from the dropdown or create one using the Create recommended role button.

Figure 2: Configuring EKS Pod Identity for Add-ons

Figure 2: Configuring EKS Pod Identity for Add-ons

Clicking on the Create recommended role button launches the IAM console in a separate browser tab, with all the information needed to create the role automatically prefilled. This includes the AWS Managed Policy, the trust policy, the role name, and the description.

Figure 3: Selecting EKS Pod Identity as the trusted entity

Figure 3: Selecting EKS Pod Identity as the trusted entity

 

Figure 4: Adding permissions to the role

Figure 4: Adding permissions to the role

 

Figure 5: Completed permissions for the role

Figure 5: Completed permissions for the role

You can review the information and click on Create Role. Retaining the default role name would enable EKS to automatically use the role when the corresponding add-on is added to other clusters in the same account. Overriding the role name would require customers to manually select the role from the dropdown.

Figure 6: EKS Add-on configuration

Figure 6: EKS Add-on configuration

Proceed to the Review and Create step and create the cluster. Once the cluster becomes active, you will see the list of add-ons installed along with EKS Pod Identity in the Add-ons tab.

Figure 7: View of installed add-ons in the console

Figure 7: View of installed add-ons in the console

Conclusion

The integration between EKS add-ons and EKS Pod Identity simplifies IAM permission management, providing a more streamlined and secure approach to configuring service account permissions for add-ons. By enabling you to easily discover and apply specific permissions during cluster creation or at any subsequent point, this integration eliminates the previous complexity associated with add-on access management where Pod Identities could not be applied for add-ons selected during cluster creation.

You can now apply different permissions to different service accounts within a single add-on, enabling you to implement the principle of least privilege more effectively. This approach not only enhances security by minimizing potential access risks but also streamlines the add-on deployment workflow with recommended IAM permissions. As Kubernetes ecosystems continue to grow in complexity, the EKS add-ons and Pod Identity integration offers a robust solution that balances security, flexibility, and ease of management, offering a streamlined solution for managing add-on permissions in Kubernetes clusters.

Call to action

Give Simplified IAM permissions for Amazon EKS add-ons a spin!

Ready to simplify your Kubernetes cluster management? With EKS Pod Identities, you can now effortlessly configure IAM permissions for EKS add-ons. Say goodbye to complex manual role configurations and hello to a more intuitive approach. Just a few clicks, and you’ll have a more streamlined way to manage IAM permissions for your cluster add-ons.

Check out our containers roadmap!

If you have ideas about how we can improve Amazon EKS add-ons or other aspects of our container services, then please use our containers roadmap to provide us feedback and review our existing roadmap items.

View the full article

  • Quote

    • Join the conversation

    You can post now and register later. If you have an account, sign in now to post with your account.

    Guest
    Reply to this topic...
    Go to topic listing