# EKS Platform Operations Guide

Use this reference for Amazon EKS platform operations across cluster access, Kubernetes RBAC, IRSA, EKS Pod Identity, node groups, Karpenter, VPC CNI, add-ons, upgrades, observability, autoscaling, ingress, and multi-tenant workload safety.

## What people get wrong

The lazy story is:

> EKS is Kubernetes, so standard cluster checks are enough.

Wrong. EKS failures sit at the AWS/Kubernetes seam: IAM-to-RBAC mapping, pod identity, CNI IP exhaustion, security group boundaries, add-on drift, node lifecycle, and control-plane version skew.

Common bad assumptions:

- Cluster admin in Kubernetes is the same as AWS account admin.
- IRSA or Pod Identity automatically enforces least privilege.
- Managed node groups remove node lifecycle risk.
- Karpenter fixes capacity without disruption risk.
- VPC CNI networking behaves like overlay networking.
- Add-on upgrades are low risk if the cluster version is supported.

## EKS failure modes

- Access entries, aws-auth, IAM roles, and Kubernetes RBAC create hidden privilege paths.
- Service accounts share broad roles or trust policies across namespaces.
- Pods cannot schedule due to IP exhaustion, security groups for pods, taints, topology spread, or PDB constraints.
- Karpenter/node group changes drain critical workloads without disruption budget evidence.
- CNI/CoreDNS/kube-proxy/add-on drift breaks networking or DNS.
- Cluster upgrade ignores API deprecations, webhook compatibility, managed add-ons, and workload tests.

## Minimum safe workflow

1. Identify cluster version, endpoint exposure, accounts/Regions, node strategy, add-ons, and tenant model.
2. Review access control: IAM principals, access entries/aws-auth, Kubernetes RBAC, IRSA/Pod Identity, and break-glass.
3. Check workload safety: namespaces, network policies, pod security, secrets, image provenance, and resource limits.
4. Check capacity and networking: node groups, Karpenter, VPC CNI IPs, subnets, security groups, load balancers, and ingress.
5. Check operations: upgrades, PDBs, autoscaling, observability, backups, runbooks, and incident history.
6. Recommend staged, reversible changes with drain/rollback plans.
7. Never mutate cluster access, node groups, add-ons, or workloads without explicit approval.

## Verification targets

- EKS cluster version, endpoint access, access entries/aws-auth, IAM roles, Kubernetes RBAC, and audit logs
- IRSA/Pod Identity service account mappings, trust policies, namespace scoping, and token audience boundaries
- managed node groups, self-managed nodes, Karpenter NodePools/NodeClasses, AMIs, labels, taints, and disruption settings
- VPC CNI config, subnet IP capacity, security groups for pods, network policies, ingress/load balancer controller, and DNS/CoreDNS health
- add-on versions, upgrade insights, deprecated APIs, PDBs, HPA/KEDA/Cluster Autoscaler, metrics/logs/traces, and backup/restore evidence
- workload readiness, rollout strategy, image scanning, secrets handling, and incident/change timeline

## When to push back

Push back if the user asks to:

- grant cluster-admin broadly to unblock access
- upgrade EKS without deprecated API and add-on compatibility checks
- change Karpenter/node disruption settings without PDB and workload impact review
- ignore VPC CNI IP capacity or subnet constraints
- treat IRSA/Pod Identity as least privilege without policy review
- mutate production cluster state from advisory evidence alone

# Official sources

Use this reference only when you need source grounding for AWS service behavior or the detailed source list.

## AWS documentation

Use these as starting points, not as proof of the user's live AWS state:
- https://docs.aws.amazon.com/eks/latest/userguide/creating-access-entries.html
- https://docs.aws.amazon.com/eks/latest/best-practices/cluster-upgrades.html
- https://docs.aws.amazon.com/eks/latest/userguide/eks-add-ons.html
- https://docs.aws.amazon.com/eks/latest/userguide/security-iam.html

## Grounding rule

Official documentation explains AWS service behavior. It does not prove the user's current account, Region, quota, resource configuration, IAM boundary, pricing, entitlement, or operational state. Prefer read-only AWS MCP or CLI evidence, repository evidence, or sanitized user-provided evidence for current-state claims.

## Current MCP/documentation refresh (2026-06-02)

Service facts from official docs:
- EKS access entries associate IAM principal ARNs with Kubernetes access, Kubernetes groups, and EKS access policies; they are a control point for cluster access review.
- EKS cluster upgrade best-practice guidance is relevant to platform operations because control plane, node, add-on, and workload compatibility can break independently.

Sampled live evidence:
- Read-only regional availability sampling reported Amazon EKS as `isAvailableIn` in `us-east-1`, `us-west-2`, `eu-west-1`, and `ap-southeast-1`.
- Sampled APIs `EKS+DescribeCluster` and `EKS+ListAddons` were reported `isAvailableIn` in those regions.

Review implications:
- Do not approve EKS posture without evidence for cluster version, add-ons, node groups/Fargate profiles, access entries/RBAC, IRSA or pod identity, network policy, logging, and upgrade/rollback plan.
- Regional service availability does not prove account quota, cluster health, add-on compatibility, or Kubernetes object state.

# Safety checklist

Use this reference before privileged, destructive, traffic-changing, cost-changing, compliance-impacting, or production-impacting recommendations.

## Non-negotiables

- Never ask users to paste secrets, access keys, session tokens, private keys, customer identifiers, or sensitive account data into chat.
- Use read-only AWS MCP or read-only AWS CLI evidence for live state when available; otherwise use repository evidence, sanitized user evidence, or official documentation and label the evidence level.
- Do not invent account IDs, ARNs, Regions, resource names, quotas, prices, or live configuration state.
- Require explicit user approval before privileged, destructive, traffic-changing, cost-changing, or production-impacting actions.
- Use current official AWS documentation for service behavior when the answer depends on AWS service details.
- Keep remediation least-privilege, reversible, and scoped to the requested workload or account boundary.

## Stress checks

- What can expose data?
- What can escalate privilege?
- What can break production or block rollback?
- What can create unbounded cost?
- What compliance or audit evidence is missing?
- What rollback or validation path is unproven?

## Evidence labels

Use `live evidence`, `repo evidence`, `user-provided evidence`, `documentation-based`, or `inference`. Documentation alone never proves the user's live AWS state.

# Workflow and output contract

Use this reference only when performing the full review, implementation guidance, incident triage, or production-readiness pass.

## Review domains

Check these areas before giving a verdict:
- Cluster version/add-ons, upgrade path, node strategy, disruption budgets, and rollback
- IAM, cluster access entries, Kubernetes RBAC, service-account identity, and secrets posture
- VPC CNI, network policy, ingress, egress, DNS, and multi-tenant isolation
- Observability, audit logs, autoscaling, reliability, cost, image security, and runtime detection

## Safe workflow

1. **Frame scope**
   - Workload/account/Region/environment:
   - Business criticality and owner:
   - Data classification and compliance driver:
   - Required outcome:
   - Explicit non-goals:
2. **Collect evidence**
   - Prefer read-only AWS MCP or read-only AWS CLI evidence for current-state claims when available.
   - Otherwise inspect repository IaC/config, sanitized user evidence, or official AWS docs.
   - Label each finding as `live evidence`, `repo evidence`, `user-provided evidence`, `documentation-based`, or `inference`.
3. **Stress-test risk**
   - What can expose data?
   - What can escalate privilege?
   - What can break production or block rollback?
   - What can create unbounded cost?
   - What evidence is missing?
4. **Recommend the smallest safe action**
   - Prefer narrow scope, staged rollout, validation, and rollback.
   - If the safest action is to stop and gather evidence, say that plainly.

## Output contract

Return this structure:
```markdown
# AWS EKS Platform Operator: <scope>
## Executive verdict
- Status: READY / READY WITH RISKS / NOT READY / NEEDS EVIDENCE
- Biggest risk:
- Evidence level:
## Scope and assumptions
- Confirmed:
- Unknown:
- Out of scope:
## Findings
| Severity | Finding | Evidence | Why it matters | Minimum safe action |
|---|---|---|---|---|
## Recommended actions
1. <action> — owner: <owner>, validation: <check>, rollback: <rollback>
## Validation
- Commands or checks:
- Expected result:
## Residual risk
- <risk or explicit none>
```