A company is building a data stream processing application. The application runs in an Amazon Elastic Kubernetes Service (Amazon EKS) cluster. The application stores processed data in an Amazon…

Question

Options

• AStore the AWS credentials in an Amazon S3 bucket. Grant the EKS containers access to the S3
• BAttach an IAM role to the EKS worker nodes, Grant the IAM role access to DynamoDB. Use the
• CCreate an IAM user that has an access key to access the DynamoDB table. Use environment
• DCreate an IAM user that has an access key to access the DynamoDB table. Use Kubernetes

• A
  4% (1)
• B
  72% (18)
• C
  16% (4)
• D
  8% (2)

Explanation

IAM roles for service accounts (IRSA) allow assigning fine-grained permissions to EKS pods based on Kubernetes service accounts. This approach ensures that AWS credentials are not hardcoded or stored in environment variables, which enhances security. Instead, the pods running in the EKS cluster assume the IAM role with permissions to access Amazon DynamoDB This solution meets the requirement of providing secure access without embedding AWS credentials in the containers, while also allowing for more granular access control at the pod level rather than relying on the node-level IAM role. Storing AWS credentials in S3 is insecure and not a recommended practice. This approach does not meet the security requirement of avoiding embedded AWS credentials. Storing AWS credentials in environment variables is insecure and not recommended. This exposes credentials within the container, increasing the risk of credential leakage. Although Kubernetes secrets can provide some protection, storing long-term AWS credentials (access key and secret key) in secrets still presents a security risk. The preferred method is to use temporary credentials via IAM roles (IRSA), which rotate automatically.

No community discussion yet for this question.