The Kubernetes Security Checklist for AI-Built Clusters

Quick answer
A default cluster allows all pod-to-pod traffic, mounts service account tokens by default, and stores Secrets unencoded but unencrypted.
The five hardening areas are identity (RBAC), network (policies), workload (pod security), secrets (encryption and external stores), and images.
Most real compromises of a small cluster start with an over-permissioned service account or a credential in an image, not an exotic exploit.
k3s needs the same hardening as any other distribution — being small does not make it safe.
Re-run the checklist after every manifest change and upgrade, because new workloads reopen defaults you closed.

What is the Kubernetes security checklist?

It is the ordered set of changes that turns a default cluster into one where a single compromised workload cannot reach everything else. Kubernetes is secure-by-configuration, not secure-by-default: the platform refuses very little, so the posture you get is the one you configure. The checklist below is deliberately ordered by impact, so doing only the first two sections removes most of the risk.

Identity: who can do what

Give every workload its own service account with a role scoped to the verbs and resources it actually uses. Set automountServiceAccountToken to false on any pod that does not call the Kubernetes API, because a mounted token is a credential an attacker inherits. Never bind a workload to cluster-admin. This is covered in depth in What Is Kubernetes RBAC (and What Did Your AI Grant Away)?.

Network: who can reach whom

Apply a default-deny network policy per namespace, then open only the flows your application needs. Without policies, every pod can reach every other pod, so one exploited container can talk directly to your database and to the cloud metadata service. Network policies turn lateral movement from a given into a separate obstacle.

Workloads: what a container can do to the host

Set a securityContext on every workload: runAsNonRoot true, a fixed numeric runAsUser, allowPrivilegeEscalation false, drop all capabilities, and readOnlyRootFilesystem true where the app allows it. These settings stop a container from becoming a shell on the node. The image has to cooperate, so it must define a non-root user and avoid installing unnecessary tooling.

Secrets, images, and the control plane

Enable encryption at rest for the API datastore, restrict who can read Secrets, and prefer an external secrets manager over committing values. Pin images by digest, build from a minimal verified base, and scan them in CI. Finally, keep the API server and kubelet off the public internet, and turn on audit logging so you can see what happened after an incident rather than guessing.

Where this bites vibecoders
A cluster built from generated manifests passes every functional test and fails almost every security review, because the assistant optimizes for ‘it runs’. It creates a broad role so the app can read its config, leaves the default service account mounted, pastes credentials into a ConfigMap, and never sets a securityContext. None of that appears in a feature test. The checklist exists because the work is invisible until it is exploited, and a vibe-built cluster is exactly the kind that never had the pass applied.

Where AI coding assistants get this wrong

Binding workloads to broad roles or cluster-admin to make permissions ‘just work’.
Leaving service account tokens mounted into pods that never call the API.
Skipping securityContext, so containers run as root with default capabilities.
Placing credentials in ConfigMaps or environment variables instead of Secrets.
Generating no network policies, leaving every pod reachable from every other.
Ignoring encryption at rest because the Secrets look encoded.

Checklist

Give each workload a least-privilege service account.
Disable automounted tokens where the API is not used.
Add default-deny network policies and open only needed flows.
Set non-root, no-escalation securityContexts on every workload.
Enable secret encryption at rest and restrict Secret reads.
Pin and scan images; keep the API server private.
Enable audit logging and review it after changes.

FAQ

How long does hardening a small cluster take?

First pass on a small cluster is an afternoon: service accounts and roles, a default-deny policy, securityContexts on each workload, encryption at rest, and image scanning in CI. The ongoing cost is re-checking each new workload, which is minutes per change.

Do I need all of this for a hobby project?

You should do the identity and workload steps regardless, because they are quick and stop the common escalation paths. Network policies and encryption at rest matter more once the cluster holds anything a user would care about. A stolen database password does not care that the project was a hobby.

Is a managed cluster already hardened?

Partly. A managed provider secures the control plane and the API server endpoint for you, which removes a large class of risk. Everything inside the cluster — RBAC, network policies, pod security, secrets, and images — is still your responsibility.