AWS Certified Security – SpecialtyDomain 4: Identity and Access ManagementMedium

A security engineer is designing an access strategy for a new application that will process highly sensitive customer data. The application consists of multiple microservices running on Amazon EKS, and each microservice requires specific, fine-grained permissions to interact with various AWS services (e.g., S3, DynamoDB, SQS). The engineer wants to ensure that each microservice has only the permissions it needs, without sharing credentials or relying on EC2 instance profiles. How can the engineer securely manage these permissions for the EKS microservices?

  1. AUse IAM roles for Service Accounts (IRSA) to associate an IAM role with each Kubernetes service account.
  2. BStore AWS credentials as Kubernetes Secrets and inject them into each microservice pod.
  3. CGrant permissions directly to the EC2 instance profile associated with the EKS worker nodes.
  4. DCreate a single IAM role for the EKS cluster and grant it all necessary permissions for all microservices.
Show answer & explanation

Correct answer: A. Use IAM roles for Service Accounts (IRSA) to associate an IAM role with each Kubernetes service account.

IAM roles for Service Accounts (IRSA) allow you to associate an IAM role with a Kubernetes service account. This enables each microservice (running as a pod associated with a service account) to assume a distinct IAM role, granting it fine-grained, least-privilege permissions without sharing credentials.

Why the other options are wrong

  • B. Storing AWS credentials as Kubernetes Secrets is insecure as secrets are base64 encoded, not encrypted by default, and can be easily accessed.
  • C. Granting permissions to the EC2 instance profile would provide all pods on that node with the same permissions, violating least privilege for microservices.
  • D. A single IAM role for the entire cluster violates the principle of least privilege, giving all microservices overly broad access.

IAM Roles for Service Accounts (IRSA)

A feature that allows you to associate an IAM role with a Kubernetes service account, providing fine-grained permissions for pods.

  • Eliminates the need to share credentials or use instance profiles for pod identity.
  • Uses OpenID Connect (OIDC) to authenticate Kubernetes service accounts with IAM.
  • Enables fine-grained, least-privilege permissions for individual microservices.

Memory trick: Think of giving each microservice its own 'ID badge' (IAM role) inside the EKS 'office' (cluster).

More Domain 4: Identity and Access Management questions