Skip to main content

Untitled

To master IAM to RBAC mapping, you must understand how two completely different identity systems "shake hands." AWS manages the Identity (the "Who"), while Kubernetes manages the Authorization (the "What").

Here is the comprehensive guide to mastering this "Identity Handshake."

1. The Architectural Flow​

When you run a kubectl command, a complex translation happens behind the scenes to turn your AWS credentials into a Kubernetes identity.

  • Authentication (AWS): You send a request signed by your AWS IAM credentials. The EKS Cluster (via the AWS Identity service) verifies that you are a valid AWS user/role.

  • Mapping (The Bridge): EKS looks at its mapping table (either the legacy aws-auth ConfigMap or the modern Access Entries). It finds your IAM ARN and says, "Okay, this AWS Role is known as 'dev-user' inside Kubernetes."

  • Authorization (RBAC): Kubernetes takes that "dev-user" name and checks its internal RoleBindings. If a binding exists for "dev-user," the action is permitted.

2. Comparison: Legacy vs. Modern​

Mastering this topic requires knowing when to use which method.

Feature****Legacy (aws-auth)****Modern (Access Entry API)****Logic LocationInside the cluster (ConfigMap)AWS Control Plane (API)Managementkubectl editAWS CLI / Console / TerraformRiskHigh (YAML errors = Lockout)Low (API validation)VisibilityHidden in kube-systemVisible in AWS IAM/EKS ConsoleAudit TrailKubernetes Audit LogsCloudTrail + K8s Logs

3. The "Identity Transformation"​

This is the most critical part to understand. When you map a role, you define three things:

  • Principal ARN: The unique AWS ID of the user or role.

  • Kubernetes Username: An alias you give that user inside the cluster (e.g., alice-iam becomes cluster-admin).

  • Kubernetes Groups: These are the "labels" attached to that user. Kubernetes RBAC Bindings usually target Groups rather than individuals to make management easier.

> Master Tip: In DevSecOps, never map an IAM user directly. Always map IAM Roles. This allows you to rotate users in AWS without ever having to update your Kubernetes configuration.

4. The "Cluster Creator" Rule​

A common point of confusion: the IAM user or role that creates the EKS cluster does not appear in the aws-auth ConfigMap or Access Entries.

  • Behavior: AWS automatically grants the creator system:masters (God-mode) permissions.

  • Risk: If the person who created the cluster leaves the company and their IAM user is deleted, you might lose the "primary" door into the cluster.

  • Fix: Immediately after creation, use that creator's identity to map a "Break-glass" IAM Role to the system:masters group.

5. Security & DevSecOps Best Practices​

To be a master of this topic, you must apply the Principle of Least Privilege:

  • Avoid system:masters: This group bypasses all RBAC checks. Use it only for automation or emergency recovery.

  • Namespace Isolation: Use the access_scope in the Access Entry API to restrict developers to their specific namespace (e.g., marketing or payments).

  • Audit Regularly: Use the following command to see who currently has access via the modern API:Bashaws eks list-access-entries --cluster-name

  • Use Managed Policies: Whenever possible, use AWS-managed policies like AmazonEKSViewPolicy instead of writing custom Kubernetes ClusterRoles.

6. Troubleshooting the Handshake​

If you get a 403 Forbidden error, follow this mental checklist:

  • Check sts get-caller-identity: Are you actually using the IAM role you think you are?

  • Check the ARN: Does the ARN in EKS exactly match the IAM Role ARN? (Trailing slashes or path prefixes like /dev/ can cause mismatches).

  • Check the Group Name: Does the group name in your RoleBinding exactly match the group name in your Access Entry/ConfigMap?