Pod security context
Privileged containers, host namespaces and host path mounts are the routes from a compromised pod to the node. Enforce this cluster-wide with Pod Security Standards or a policy engine rather than relying on every manifest getting it right.
RBAC
Default service accounts get mounted into every pod unless you say otherwise. Turn that off where the workload doesn't call the API:
Then scope roles to specific verbs on specific resources in specific namespaces. cluster-admin bound to a workload is common and almost never necessary.
Audit with kubectl auth can-i --list as the service account in question.
Secrets
Kubernetes Secrets are base64-encoded in etcd. Anyone with read access to etcd or the API for that namespace can read them.
Enable encryption at rest on etcd, restrict access with RBAC, and for anything sensitive use an external secret store. AWS Secrets Manager, Vault, or External Secrets Operator, so the value never sits in the cluster at all.
Never commit Secret manifests. Sealed Secrets or SOPS if they must live in git.
Network policies
By default, every pod can reach every other pod. In a multi-tenant or multi-service cluster that means one compromised workload has the whole network.
Default deny per namespace, then allow the specific flows you need:
Your CNI must support them. Some don't, and the policy is silently ignored.
Images
Pin by digest. Set imagePullPolicy: Always for mutable tags. Use an admission controller to reject images from untrusted registries or without a signature.
Scan images in CI rather than at deploy time, so failures happen where someone can act on them.
Resource limits
Not obviously security, but a pod without limits can consume a node and take down everything on it. Set requests and limits on everything, and use quotas per namespace.
The API server
The most valuable target in the cluster. Restrict access to it, enable audit logging, and keep anonymous auth off. On managed clusters, use a private endpoint or restrict by source address.