Security and RBAC
ServiceAccounts, least privilege, and supply chain basics — hardening the cluster without security theater.
A cluster is a privileged API. Treat identity and permission as carefully as you treat production database credentials.
ServiceAccounts per workload
Do not run everything as the namespace default account with broad rights. Give each Deployment a dedicated ServiceAccount and bind only the API access it needs (if any). Most apps need no Kubernetes API access at all.
RBAC is allowlists
Roles/ClusterRoles plus bindings define who can get/list/watch/create. Humans, CI bots, and controllers should each have narrow scopes. cluster-admin in day-to-day human kubeconfigs is a smell.
Pod security posture
Drop unnecessary capabilities, run as non-root, read-only root filesystem where feasible, and block privileged escalation. Use the platform’s Pod Security standards / policies — do not rely on “we trust our images.”
Supply chain
Scan images, pin digests, control what registries the cluster can pull, and sign/verify when your org supports it. Admission policies beat wiki pages nobody reads.
Secrets and etcd
Encrypt Secrets at rest, restrict who can read them, and prefer external secret stores for long-lived credentials. Audit logs for Secret access matter in regulated environments.
Security on Kubernetes is mostly defaults that fail closed and boring reviews — not a single product checkbox.