Kubernetes Security: EKS Access Control Blueprint: A Complete 13-Layer ACL Framework for Kubernetes Security

by

EKS ACCESS CONTROL BLUEPRINT — COMPLETE 13-LAYER ACL FRAMEWORK (2025 Edition)

A single-page, production-ready guide for implementing ACLs across VPC, ALB, Kubernetes, and AWS APIs.

This blueprint covers every layer where access can be allowed, denied, restricted, or authenticated in an EKS Full Auto Mode cluster fronted by AWS ALB.

1. AWS Network ACLs (Subnet-Level ACLs)

Purpose: Coarse, stateless allow/deny at the VPC subnet layer.
Use Cases: Block unwanted IPs before they reach nodes; restrict subnet-to-subnet traffic.
Steps:

  • Create NACLs per subnet.
  • Allow only trusted inbound ports.
  • Deny unknown external CIDRs.
  • Restrict DB/private subnets to EKS subnet CIDRs.

2. ALB Access Controls (CIDR, Host, Header, Path, Query)

Purpose: Gate who can reach your ALB and what content they can request.
Steps:

  • Set ALB Security Group ingress to trusted CIDRs.
  • Use listener rules for host, path, header, query filtering.
  • Limit exposure by avoiding 0.0.0.0/0 where possible.

3. ALB WAFv2 WebACL (L7 Firewall)

Purpose: Application-layer ACL (SQLi, XSS, bots, geo-block, IP sets).
Steps:

  • Create a WAF ACL with AWS managed rules.
  • Add IP sets for allowlist/denylist.
  • Attach to ALB using: alb.ingress.kubernetes.io/wafv2-acl-arn: arn:aws:wafv2:...

4. Kubernetes Ingress (ALB) Annotations

Purpose: Per-application edge ACLs.
Steps:

  • Add CIDR restrictions using inbound-cidrs.
  • Enforce TLS policies.
  • Enable access logs.
  • Add authentication (OIDC/Cognito) or mTLS if required.
  • Apply path-based routing + header-based rules.

5. Kubernetes NetworkPolicies (Pod-to-Pod ACLs)

Purpose: L3/L4 internal ACL—east-west traffic control.
Steps:

  • Ensure CNI supports NetworkPolicy (Calico/Cilium/AWS NP Mode).
  • Apply:
    • default-deny ingress
    • default-deny egress
  • Explicitly allow:
    • DNS
    • ingress → web
    • web → db
    • specific egress IPs/domains

6. Kubernetes RBAC (API Access ACLs)

Purpose: ACL for Kubernetes API (resource access).
Steps:

  • Create ServiceAccounts for each workload.
  • Bind Roles (not ClusterRoles) with least-privilege verbs.
  • Deny cluster-admin to all but break-glass users.
  • Audit RBAC changes regularly.

7. Security Groups for Nodes & Pods (SGP)

Purpose: VPC-level ACLs for workloads.
Steps:

  • Harden Node SG: restrict inbound ports.
  • Enable Security Groups for Pods in EKS add-ons.
  • Attach pod-specific SGs for DB/RDS layer restrictions (pod → RDS only).

8. IRSA (IAM Roles for Service Accounts)

Purpose: AWS API ACLs per pod.
Steps:

  • Create IAM role with least privilege.
  • Annotate ServiceAccount: eks.amazonaws.com/role-arn: arn:aws:iam::123:role/app-role
  • Use IAM policy to restrict S3, DynamoDB, SQS, etc.

9. VPC Egress Controls (Outbound ACLs)

Purpose: Control outbound to internet/AWS.
Steps:

  • Place workloads in private subnets.
  • Use NAT → restrict egress ports.
  • Add VPC Endpoints for AWS APIs.
  • Apply endpoint policies (deny wildcard “*”).
  • For strong controls: deploy AWS Network Firewall for domain/port rules.

10. Pod Security Admission (PSA)

Purpose: ACL for pod security settings.
Steps:

  • Label namespaces: pod-security.kubernetes.io/enforce=restricted
  • Block privileged containers, hostPath, hostNetwork, root user.
  • Force hardened workload specs across prod namespaces.

11. EKS API Server Access Controls

Purpose: ACL for who may reach or control the cluster API.
Steps:

  • Restrict public endpoint CIDRs to office/VPN.
  • Prefer private API endpoint if possible.
  • Lock down aws-auth Access Entries.
  • Enable API audit logging for RBAC/Ingress/NetPol changes.

12. Admission Policies (Kyverno or Gatekeeper)

Purpose: Additional, programmable ACLs.
Steps:

  • Deny pods without NetworkPolicy.
  • Block use of default ServiceAccount.
  • Enforce image registry allowlists (e.g., only ECR).
  • Require labels, owners, resource limits.

13. Service Mesh L7 Authorization (Optional but Advanced)

Purpose: In-cluster L7 ACL (JWT claims, methods, paths).
Steps:

  • Enable Istio or Cilium Service Mesh.
  • Turn on mTLS cluster-wide.
  • Add AuthorizationPolicies:
    • allow only GET/POST
    • allow only JWT role=admin
    • allow specific frontend → backend routes

Leave a Comment