🔐 EKS Authentication & Authorization — Design Patterns (Interview Level)

First — say this in interview to sound senior:

“In EKS I separate identity into three planes — human access, workload access, and deployment automation — and design each differently.”

That’s a strong opener.

🧩 Layer 1 — How EKS Authentication Works (Foundation)

EKS does not use Kubernetes native users. EKS uses AWS IAM for authentication to the control plane.

Flow:

IAM identity → aws-iam-authenticator → Kubernetes RBAC mapping → permission granted

So:

• IAM = authentication
• RBAC = authorization

Interviewers want this sentence.

👤 Pattern 1 — Human User Access to EKS (kubectl access)

✅ Design Pattern — IAM + aws-auth + RBAC

Flow:

User → AWS SSO/IAM Role → mapped in aws-auth ConfigMap → Kubernetes RBAC role → namespace access

Design:

• No IAM users with keys
• Use AWS SSO / federated login
• Users assume role
• Role mapped to K8s group
• Group bound to RBAC role

✅ Example Pattern — Team Namespace Access

Platform team role → cluster-admin Team-A role → namespace-a admin Team-B role → namespace-b read/write

This prevents cross-team blast radius.

❌ Bad Pattern (interview red flag)

• mapping everyone to system:masters
• giving cluster-admin to all engineers
• using static IAM users with access keys

🧑‍💻 Pattern 2 — CI/CD Deployment to EKS

This is heavily asked.

✅ Design Pattern — CI Role + Namespace RBAC

CI system (Jenkins/GitHub Actions) assumes dedicated IAM role → mapped in aws-auth → mapped to limited K8s RBAC → deploy only allowed namespaces.

Why:

• no personal creds in pipeline
• auditable
• revocable
• least privilege

✅ Production Guardrail

Separate roles:

ci-dev-deployer ci-stage-deployer ci-prod-deployer

Each mapped to env namespace only.

📦 Pattern 3 — Pod → AWS Resource Access (Very Important)

This is NOT kubectl auth — this is runtime auth.

✅ Best Practice — IRSA (IAM Roles for Service Accounts)

ServiceAccount ↔ IAM Role binding via OIDC.

Pod uses service account → gets IAM role → calls AWS APIs.

Why this is best:

• pod-level least privilege
• no node-role overpermission
• no static keys
• audit trail per workload

❌ Bad Pattern

Using node instance role for all pods. One pod compromise → full node IAM permissions.

Interviewers expect you to call this out.

🏢 Pattern 4 — Multi-Team Cluster Access Model

Senior-level answer:

✅ Namespace + IAM Role + RBAC Binding Model

Per team:

IAM role per team mapped → k8s group group → namespace rolebinding namespace quotas + network policies enforced

✅ Add Guardrails

• OPA/Kyverno policies
• resource quotas
• limit ranges
• network policies
• PodSecurity standards

Auth without guardrails is incomplete design.

🔐 Pattern 5 — Fine-Grained Authorization Inside Cluster

✅ RBAC Levels You Should Mention

ClusterRole — cluster scope Role — namespace scope RoleBinding — attach to subject ClusterRoleBinding — global attach

Best practice → namespace RoleBindings for teams.

🌍 Pattern 6 — External Identity Provider Integration

✅ OIDC / SSO Integration Pattern

Enterprise fintech pattern:

IdP (Okta/Azure AD) → AWS SSO → IAM roles → EKS RBAC mapping

Benefits:

• central offboarding
• MFA enforced
• audit trail
• no local IAM users

🚦 Pattern 7 — Read-Only Access for Auditors / Support

Create IAM role → mapped to k8s read-only cluster role → view-only access.

Important for fintech audits.

🧠 Pattern 8 — Break-Glass Admin Access

Have emergency admin role:

• MFA required
• session logged
• approval workflow
• not used daily

Interview gold answer.

⚠️ Limits & Gotchas Interviewers Like

aws-auth ConfigMap is critical

• misconfig → lockout
• must be version controlled
• GitOps manage it
• backup mapping roles

Token lifetime

kubectl tokens are short-lived (STS). Good for security — may surprise users.

🧱 Full Secure EKS Access Architecture (What to Say)

Say this in interview:

Human users authenticate via SSO → assume IAM roles → mapped to RBAC groups. CI/CD uses dedicated deployer roles with namespace-scoped RBAC. Workloads use IRSA for AWS access. Guardrails enforced via policy engine and quotas. No static credentials, no shared admin, and access is namespace-isolated.