Examkin

Question

Difficulty: HardAWS SDKs and Credential Management

A developer is migrating a Python application from an Amazon EC2 instance to an Amazon EKS cluster. The application uses the AWS SDK for Python (Boto3) to access an Amazon DynamoDB table. On the EC2 instance, the application successfully used the instance profile credentials. In the EKS cluster, the application fails to authenticate, resulting in a NoCredentialsError.

The EKS ServiceAccount has been annotated with the role ARN arn:aws:iam::123456789012:role/my-dynamodb-role, and the environment variables AWS_ROLE_ARN and AWS_WEB_IDENTITY_TOKEN_FILE are correctly injected into the container. However, the application code initializes the client using boto3.Session(aws_access_key_id=access_key, aws_secret_access_key=secret_key) where the keys are read from a configuration file that is not present on EKS.

Which two changes should the developer make to resolve this authentication issue and securely run the application on EKS? (Select two.)

  1. Modify the Python code to initialize the Boto3 client using the default session: boto3.client('dynamodb').Answer
  2. Configure the IAM role's trust policy to trust the EKS cluster's OIDC provider and allow the sts:AssumeRoleWithWebIdentity action.Answer
  3. C
    Modify the IAM role's trust policy to trust the eks.amazonaws.com service principal and allow the sts:AssumeRole action.
  4. D
    Update the Python code to manually parse the web identity token file, call the sts:AssumeRole API, and configure static credentials in the Boto3 client constructor.
  5. E
    Configure AWS Systems Manager Parameter Store to store the IAM role's temporary credentials and retrieve them using the Boto3 client on application startup.

Answer

Initialize the Boto3 client using the default session (boto3.client('dynamodb')) and configure the IAM role's trust policy to trust the EKS cluster's OIDC provider using the sts:AssumeRoleWithWebIdentity action.
To successfully migrate the application to Amazon EKS using IAM Roles for Service Accounts (IRSA), two components are required. First, the application code must utilize the SDK's default credential provider chain (e.g., using default client initialization without passing static keys) so that the SDK automatically detects the environment variables injected by EKS (AWS_ROLE_ARN and AWS_WEB_IDENTITY_TOKEN_FILE) and retrieves temporary credentials. Second, the IAM role's trust policy must trust the EKS cluster's OIDC identity provider and allow the sts:AssumeRoleWithWebIdentity action, enabling the token to be exchanged for temporary IAM credentials.

Step-by-Step Solution

1
Remove explicit credential arguments from the Boto3 client initialization code.
The application code is modified from using boto3.Session(aws_access_key_id=..., aws_secret_access_key=...) to using the default constructor boto3.client('dynamodb').
This enables the AWS SDK's default credential provider chain to look for credentials in the EKS environment, specifically using the injected AWS_ROLE_ARN and AWS_WEB_IDENTITY_TOKEN_FILE environment variables.
2
Configure OIDC trust for the IAM role.
The IAM role's trust policy is updated to include the EKS OIDC identity provider URL as a trusted federated principal.
This allows EKS pods to exchange their service account tokens for temporary AWS credentials using the Security Token Service (STS).
3
Allow the sts:AssumeRoleWithWebIdentity action in the trust policy.
The trust policy grants permissions for the sts:AssumeRoleWithWebIdentity action to the OIDC identity provider principal.
Without this action allowed, the STS exchange will fail, causing authentication errors when the SDK tries to assume the role.

Key Concept

AWS SDK credential resolution and IAM Roles for Service Accounts (IRSA) configuration using OIDC and sts:AssumeRoleWithWebIdentity.
Rate this question

Topics

AWS SDKs and Credential Management

More questions from this topic