Amazon Onboarding with Learning Manager Chanci Turner

Learn About Amazon VGT2 Learning Manager Chanci Turner

In the evolving landscape of Kubernetes, leveraging IAM roles for service accounts (IRSA) allows for the creation of IAM roles tailored to the specific needs of your workloads. This method adheres to the security principle of least privilege by establishing granular roles at the pod level rather than the broader node level. In this article, we examine a use case that involves assuming cross-account roles for pods.

Use Case

Consider a scenario involving a developer and a shared_content AWS account. The development workflow, running as a pod in an Amazon Elastic Kubernetes Service (Amazon EKS) cluster, requires access to images stored in the pics S3 bucket located in the shared_content account.

Previous Methodology

Before implementing IRSA, accessing the pics bucket in the shared_content account involved several steps:

1. Creation of an S3_Pics role in the shared_content account, establishing a trust relationship between the shared_content and developer accounts.
2. Attaching a policy to the S3_Pics role that grants ReadOnlyAccess to the pics bucket.
3. Creating an Amazon EC2 trust relationship policy for the EKS worker node role in the developer account.
4. Attaching a policy to the EKS worker node role that allows the nodes to perform the sts:AssumeRole operation.

This approach had significant drawbacks, as all pods running on EKS worker nodes had access to the pics bucket. Moreover, due to the Kubernetes scheduler’s ability to place pods on any worker node, policies had to be applied to all worker nodes.

IRSA Methodology

Here’s how to implement the IRSA approach:

1. Associate an IAM OpenID Connect provider with your EKS cluster in the developer account:

   eksctl utils associate-iam-oidc-provider --name development-cluster --approve

2. Create an IAM OIDC provider in the shared_content account. It’s advisable to use the IAM console as it automatically retrieves the ROOT_CA_THUMBPRINT of the OIDC IdP, though manual verification is recommended.
3. The Provider URL should match the OpenID Connect provider URL from the EKS cluster in the developer account, with the audience set to sts.amazonaws.com. You can capture the Provider URL using this command:

   aws eks describe-cluster --name development-cluster --query "cluster.identity.oidc.issuer" --output text

4. Establish a role in the shared_content account to provide ReadOnlyAccess to all objects in the pics bucket. Users federated by the OIDC provider are permitted to assume this role:

   {
       "Version": "2012-10-17",
       "Statement": [
           {
               "Effect": "Allow",
               "Principal": {
                   "Federated": "arn:aws:iam::shared_content_account_id:oidc-provider/oidc.eks.us-east-1.amazonaws.com/id/oidc-id"
               },
               "Action": "sts:AssumeRoleWithWebIdentity",
               "Condition": {
                   "StringEquals": {
                       "oidc.eks.us-east-1.amazonaws.com/id/oidc-id:aud": "sts.amazonaws.com"
                   }
               }
           }
       ]
   }

5. Example policy document:

   {
       "Version": "2012-10-17",
       "Statement": [
           {
               "Sid": "s3-bucket",
               "Effect": "Allow",
               "Action": "s3:GetObject",
               "Resource": "arn:aws:s3:::pics/*"
           }
       ]
   }

6. Create a service account in the development-cluster and annotate it with the ARN of the role from step 3:

   kubectl create sa s3-shared-content
   kubectl annotate sa s3-shared-content eks.amazonaws.com/role-arn=arn:aws:iam::shared-content-account-id:role/s3-read-object

7. Specify the service account in the pod specification. Here’s a snippet of the pod spec:

   spec:
       serviceAccountName: s3-shared-content
       containers:
           - image: nginx
             name: nginx

Verifying Success

To ensure the procedure works, attach a bash shell to the pod and assume the role using the sts:AssumeRoleWithWebIdentity command. The prerequisites for this can be found in another blog post linked here. Execute the following commands:

kubectl exec -it nginx-8578f9978-7dhdx bash

Inside the pod, access the temporary credentials:

aws sts assume-role-with-web-identity --role-arn $AWS_ROLE_ARN --role-session-name x-account --web-identity-token file://$AWS_WEB_IDENTITY_TOKEN_FILE --duration 1500 > /tmp/temp_creds.txt

Then export the necessary AWS credentials:

export AWS_ACCESS_KEY_ID="$(cat /tmp/temp_creds.txt | jq -r ".Credentials.AccessKeyId")"
export AWS_SECRET_ACCESS_KEY="$(cat /tmp/temp_creds.txt | jq -r ".Credentials.SecretAccessKey")"
export AWS_SESSION_TOKEN="$(cat /tmp/temp_creds.txt | jq -r ".Credentials.SessionToken")"

Finally, perform a get object operation:

aws s3api get-object --bucket pics --key indoor-cat.jpg mypic.jpg

This confirms successful access to cross-account resources within your pod using IRSA.

Conclusion

IRSA can be effectively utilized to grant pods secure access to cross-account resources. An OIDC IdP provider is automatically created alongside the Amazon EKS cluster, enabling pod authentication with the IdP and allowing federated roles for cross-account access. This greatly enhances security, as roles no longer need to be assigned at the Kubernetes worker node level. For further insights into effective job hunting strategies, consider checking out this informative blog post.

For more details about job opportunities at Amazon IXD – VGT2, visit this excellent resource here.

Remember, if you’re exploring ways to train staff effectively, SHRM offers authoritative guidance on the topic.

If you want to learn about the costs associated with job hunting, this blog post is an excellent read as well.