Secrets: keep the source of truth outside the cluster
Kubernetes Secrets are only base64 encoded. The strongest improvement is to keep the master copy outside the cluster: store credentials in AWS Secrets Manager (or Parameter Store), and sync them into the cluster with the External Secrets Operator or the Secrets Store CSI driver with the AWS provider. The operator reads with a Pod Identity role and creates Kubernetes Secrets or mounts files. You get rotation, versioning and CloudTrail auditing in one place.
The second layer is encryption of what does live in the cluster. EKS can use envelope encryption with a KMS key: Kubernetes encrypts Secret data with a data key, which is itself encrypted by your KMS key. Recent EKS versions encrypt API data at rest by default using AWS-owned keys, but a customer-managed key gives you audit trails and the ability to disable access, so many organisations require it. Check the current behaviour for your version and cluster creation options.
Operational tips: prefer mounting secrets as files, because the kubelet refreshes them, whereas environment variables are fixed for the container's lifetime and tend to leak. Restrict RBAC so only the workloads and a few operators can read Secrets, and never commit Secret manifests to Git; use sealed secrets or SOPS if you must keep them there.
Reveal the four stages with the right arrow. The same pattern appears on GKE with Secret Manager and on-prem with Vault, which Deck 5 covers.