Eks Security

EKS Security & Compliance

End-to-end, opinionated security and compliance guidance for Amazon EKS, structured as a 7-layer stack plus a compliance-regime cross-cutting view. This skill is discovery-driven — the right hardening stack is a function of (compliance regime × OS-standardization mandate × team skill × audit timeline × workload sensitivity × air-gap requirement × scale × operational-overhead tolerance). Skipping the discovery questions makes the recommendation wrong about half the time.

Two AWS-published guides are the canonical foundation and every recommendation must align with one or both: the EKS Best Practices: Compliance guide and the EKS Best Practices: Runtime Security guide. For "how do I run a single cluster well" (non-security) use eks-best-practices; for designing/building the cluster use eks-design / eks-build.

The accuracy bar (non-negotiable for this skill). Compliance is the one domain where customers validate every claim against an auditor. Compliance status changes over time — always defer to the live AWS Services in Scope page before quoting program coverage in any customer-facing document. Never state a cryptographic-module status, FedRAMP boundary, or certification you cannot cite to an AWS-published source. When you can't ground a claim, say so — do not synthesize.

When to Use This Skill

Activate when the user wants to:

• Harden an EKS cluster or prepare for a first-time compliance audit (HIPAA, PCI-DSS, FedRAMP, SOC 2, ISO 27001, GDPR, HITRUST, NIST 800-53/171)
• Choose an OS / AMI strategy for security (Bottlerocket vs AL2023-with-CIS vs Ubuntu Pro vs RHEL vs Auto Mode)
• Decide identity & access (EKS Pod Identity vs IRSA; Access Entries vs aws-auth)
• Apply workload security (Pod Security Admission, Kyverno/OPA, NetworkPolicy, Security Groups for Pods)
• Secure the image supply chain (ECR Enhanced Scanning, Cosign/Notation signing, admission verification)
• Add runtime security (GuardDuty for EKS, Falco) and audit logging (control-plane logs, CloudTrail, SIEM)
• Wire compliance accelerators (Audit Manager, Config, Security Hub, Artifact)

Don't use this skill for:

• Non-EKS container platforms — ECS/Fargate-without-EKS (defer to ECS security guidance) or ROSA (Red Hat manages the stack differently)
• AWS account-level / org-wide security with no EKS-specific angle (IAM org policy, SCPs, SSO, multi-service GuardDuty) → Security guidance, not this skill
• GenAI/GPU workload security specifically (model-artifact provenance, training-data confidentiality, GPU-node compliance) → eks-genai
• Generic EKS architecture/cost/upgrade decisions with no security driver → eks-best-practices / eks-design
• Generating Terraform/Helm (→ eks-build) or auditing a live cluster's operational posture (→ eks-operation-review)

Discovery First — the Required Questions

Do NOT recommend a hardening stack before answering these. The single most common mistake is reflexively saying "use Bottlerocket" or "use AL2023 with CIS hardening" without confirming the customer's context. The first four answers alone determine ~80% of the recommendation.

1. Compliance regime(s)? None / SOC 2 / HIPAA / PCI-DSS / FedRAMP Moderate / FedRAMP High / GDPR / ISO 27001 / HITRUST / NIST 800-53/171 / CJIS / DISA IL5 — rank primary/secondary if multiple.
2. Workload sensitivity? Public / internal / PII / PHI (HIPAA) / cardholder data (PCI) / federal.
3. OS / AMI strategy? Open to AWS defaults / Bottlerocket-first / AL2023+CIS custom AMI / Ubuntu mandate / RHEL mandate / custom hardened / EKS Auto Mode.
4. Audit timeline? None / <3 mo (urgent) / 3-6 mo / 6-12 mo / continuous.
5. Cluster topology? Single vs multi-cluster, single vs multi-account, multi-region, EKS Anywhere, Hybrid Nodes, GovCloud.
6. Team K8s/security skill? Low / moderate / high / mixed.
7. Operational-overhead tolerance? Zero (managed-only) / low / moderate / high.
8. Current security tooling baseline? None / AWS-native / third-party CNAPP / OSS / hybrid.

Full required + recommended question set, the 5 adoption-challenge archetypes, and the 8-step response framework: references/engagement-and-response.md.

The 7-Layer Security & Compliance Stack

Walk the layers bottom-up on a first engagement; each layer's controls compound on the previous.

The AWS-canonical reference stack for a new commercial cluster: Bottlerocket (L1) + Pod Identity + Access Entries (L2) + PSA restricted + Kyverno + VPC CNI NetworkPolicy + Security Groups for Pods (L3) + ECR Enhanced Scanning + Cosign signing (L4) + GuardDuty for EKS (L5) + control-plane audit+authenticator logging + CloudTrail (L6) + Audit Manager + Config + Security Hub (L7). The vendor-OS path applies the same stack with a Layer-1 substitution only.

Cross-cutting concerns (span every layer, aligned to the AWS Best Practices security areas): data encryption & secrets management (default envelope encryption on K8s 1.28+, CMK, Secrets Manager/CSI/ESO) → encryption-and-secrets.md; multi-tenancy & multi-account isolation (soft vs hard, namespaces→cluster-/account-per-tenant) → multi-tenancy.md; incident response & forensics (the runbook when a detection fires) → incident-response-and-forensics.md; and the shared-responsibility model — AWS secures the control plane (control-plane nodes + etcd) and assumes more as you move self-managed → MNG → Fargate; you secure the data plane, node OS, workloads, and the controls in this skill. Each reference includes its per-layer shared-responsibility split.

Compliance-Regime Scope (cross-cutting)

EKS is natively in scope for PCI-DSS L1, HIPAA-eligible (BAA required), SOC 1/2/3, ISO 27001/27017/27018/9001, FedRAMP Moderate (commercial) and High (GovCloud only), HITRUST CSF, IRAP, C5, K-ISMS, ENS High, OSPAR, DISA IL4/IL5 (GovCloud only — commercial reaches IL2). AWS provides alignment / framework support (not independent attestation) for GDPR, NIST SP 800-53/800-171, and CJIS — the customer owns workload-level controls. Per-regime nuance, the scope table, and the worked HIPAA/PCI/FedRAMP/GDPR/Auto-Mode scenarios: references/compliance-regimes.md.

Always include the disclaimer in customer-facing output: "Compliance status changes over time — verify on the live AWS Services in Scope page before quoting program coverage." And precision matters: EKS is HIPAA-eligible (with a signed BAA), not "HIPAA-compliant"; FedRAMP High = GovCloud only, Moderate = commercial regions.

Security Baseline (non-negotiable — every recommendation includes this)

Regardless of regime, every hardening recommendation MUST include:

• EKS Pod Identity (recommended for new workloads; IRSA is a fully supported alternative — see note) — never static AWS keys
• EKS Access Entries for cluster access — never the aws-auth ConfigMap on new clusters
• EKS control-plane logging — audit + authenticator at minimum
• GuardDuty for EKS — EKS Protection (audit-log) + Runtime Monitoring (agent)
• ECR Enhanced Scanning on all production repositories
• Pod Security Admission restricted on production namespaces
• NetworkPolicy default-deny on production namespaces (VPC CNI native, or Calico/Cilium on self-managed)
• Encryption at rest — EKS provides default envelope encryption of all Kubernetes API data (KMS provider v2, AWS-owned key) on K8s 1.28+ with no action required; bring a customer-managed KMS key (CMK) for control over rotation/audit, and use CMKs for EBS/S3/EFS under compliance regimes (etcd EBS volumes are also EBS-encrypted independently)
• Encryption in transit — TLS in-cluster; mTLS via service mesh for high-sensitivity workloads
• Secrets via Secrets Manager + Secrets Store CSI Driver + ASCP (or External Secrets Operator) — never plain Kubernetes Secrets in production; never baked into images
• CloudTrail for EKS API audit; private API endpoint (or restricted public CIDR allowlist) for production
• Preventive governance (multi-account): enforce the above with EKS IAM condition keys in SCPs/IAM (private endpoint, CMK encryption, approved K8s version, deletion protection) so non-compliant clusters can't be created — see identity-and-access.md