Kubernetes Security for AI Builders: Hardening the Cluster Your Assistant Configured

Quick answer

• A fresh cluster is open by design: all pods can reach all pods, service account tokens are mounted, and Secrets aren’t encrypted.
• The five hardening areas are identity (RBAC), network (policies), workload (pod security), secrets (encryption and external stores), and images (supply chain).
• Most real breaches of a small cluster are an over-permissioned service account, a credential in a container image, or an exposed API server — not exotic exploits.
• k3s changes none of this. A single-node cluster still needs the same least-privilege posture.
• Work through The Kubernetes Security Checklist for AI-Built Clusters, then the deep-dive guides linked below.
• The operations picture is in Kubernetes for AI Builders; this page is only about security.

Why Kubernetes security is different from app security

Application security asks whether a request can do something it shouldn’t. Kubernetes security asks a narrower, blunter question first: what is this workload allowed to reach inside the cluster? A default cluster answers “everything.” Any pod can open a connection to any other pod, and most pods carry a service account token that can call the Kubernetes API.

That matters because the cluster is where your blast radius lives. A path-traversal bug in one service is a data-loss incident if the same network reaches your database and a full compromise if that service also holds a token that can read every Secret in the namespace. The app-layer bug is often unavoidable; the mutation, cloud-metadata reach, and API access are not.

The defaults that are insecure out of the box

Four properties of a stock cluster explain most of the risk, and none appear in the YAML your assistant generates:

• No network policy. Every pod can talk to every other pod and to the metadata service.
• Automounted service account tokens. Every pod gets a token it usually doesn’t need.
• Unencrypted Secrets. Values are base64-encoded — reversible, not confidential.
• Root containers. Nothing in a generated manifest sets securityContext, so the process runs as whatever the image specified, often root.

Each one is fixable with a small amount of explicit configuration. The rest of this page is the order to do it in.

Identity: RBAC and service accounts

RBAC is the cluster’s permission system, and the generated default is usually a namespace-wide role granted to every workload. The fix is per-workload service accounts with roles scoped to the exact verbs and resources each one needs, plus automountServiceAccountToken: false for anything that never calls the API. Deep dive: What Is Kubernetes RBAC (and What Did Your AI Grant Away)?. For the broader identity picture — most credentials in a modern system belong to software, not people — see What Is a Non-Human Identity (NHI)? and the OWASP Non-Human Identity Top 10.

Network: default-allow is the problem

A cluster with no network policies is flat: every workload is one hop from every other. Network policies turn it into a set of explicit conversations — the API can reach the database, the frontend can reach the API, and nothing else, including anything that shouldn’t exist at all. Even a handful of policies turns an exploited container from “lateral movement” into “dead end.” Deep dive: What Is a Kubernetes Network Policy?. This is the same deny-by-default reasoning as What Is Zero Trust Architecture?, applied inside the cluster.

Workloads: pod security

Pod security is about what a container is allowed to do to the host. The high-value settings are non-obvious to an assistant that has never run an admissions controller: runAsNonRoot, a fixed numeric runAsUser, allowPrivilegeEscalation: false, dropping all Linux capabilities, and a read-only root filesystem. A container that runs as root with a writable filesystem and CAP_SYS_ADMIN is effectively a shell on the node. Deep dive: Kubernetes Pod Security: Why Your AI’s Container Runs as Root. The image itself has to support this — start from How to Write a Secure Dockerfile.

Secrets: base64 is not encryption

A Kubernetes Secret is not secret by default. It’s base64-encoded, which is a transfer encoding, not cryptography, and anyone with get on Secrets in the namespace can read the plaintext. Three moves help: enable encryption at rest for the API’s datastore, restrict get and list on Secrets with RBAC so only the workloads that need them can read them, and prefer an external secrets manager that syncs values into the cluster rather than committing them. Deep dives: Are Kubernetes Secrets Actually Secret? and How to Manage Secrets and Environment Variables Properly. If a credential has already landed in an image or a manifest, How to Scan Your Codebase for Hardcoded Secrets and How to Find and Remove Secrets From Git History are the cleanup path.

Images and the software supply chain

Everything you run is somebody’s image, and the cluster trusts it completely. Sign and scan images, pin them by digest rather than a floating tag, build from a verified base, and run a vulnerability scanner in CI so the check happens before deployment. What Is a Software Supply Chain Attack?, What Is a Container Registry (and How Do Rate Limits Work)?, and How to Add Security Scanning to Your CI/CD Pipeline cover the pipeline from base image to running pod. This is also where What Is Slopsquatting (AI Package Hallucination Attacks)? bites: an image whose dependencies were chosen from a hallucinated package name is compromised before it ships.

The control plane and the API server

The API server is the keys to the cluster. Two rules cover the common mistakes: never expose it to the public internet with a permissive authentication mode, and never mount a kubeconfig with cluster-admin into a workload. On a cloud provider, restrict the control-plane endpoint to known addresses; on a single-node k3s install, bind the API to the private interface and reach it over SSH or a VPN. The kubelet’s read-only port and the metrics endpoints are the other things scanners look for.

Detection: audit logs and runtime alerts

Prevention fails eventually, so know what the cluster did. Enable API audit logging and ship it off the node, watch for the patterns that indicate escalation (creating cluster roles, reading Secrets in bulk, exec into pods), and use a runtime security tool that flags unexpected process execution inside containers. The same outside-in principle as How to Get Alerted When Your Site Goes Down applies: alert on what you can’t see yourself.

Where this bites vibecoders

The scenario repeats almost verbatim. An assistant is asked to “get the app running on Kubernetes.” It creates a Deployment, a Service, and — because the app needs to read a config — it also creates a service account bound to a broad role and pastes the database password into a ConfigMap “for now.” The app works. Months later a dependency with a known RCE is exploited in one container; because nothing ever set securityContext, it’s running as root, and because there are no network policies, it reaches the database Service directly. The AI didn’t write insecure code on purpose — it wrote the shortest manifest that would run, and every security decision that should have been explicit was left at its permissive default. Your job is to revisit those defaults deliberately, once, with a checklist.

Where AI coding assistants get this wrong

• Binding workloads to broad roles or cluster-admin instead of a scoped role.
• Leaving automountServiceAccountToken on for pods that never call the API.
• Never setting securityContext, so containers run as root with default capabilities.
• Putting credentials in ConfigMaps, env vars, or the image instead of Secrets.
• Assuming Secrets are encrypted, and skipping encryption at rest.
• Generating no network policies, leaving the cluster flat.
• Deploying images by floating tag with no scan or signature.
• Exposing the API server or kubelet “temporarily” and never closing it.
• Treating k3s as exempt from hardening because it’s small.

Checklist

• Give every workload its own service account with least-privilege RBAC.
• Disable automounted service account tokens where the API isn’t needed.
• Add deny-by-default network policies, then open only required flows.
• Set pod and container securityContext to non-root, no escalation, capabilities dropped.
• Enable encryption at rest and lock down who can read Secrets.
• Keep credentials out of ConfigMaps, images, and Git; use an external secret store.
• Pin images by digest and scan them in CI.
• Restrict the API server and kubelet to private networks.
• Turn on audit logging and ship it off the node.
• Re-run the whole checklist after any manifest change or upgrade.

FAQ

Is Kubernetes secure by default?

No. A default cluster allows all pod-to-pod traffic, gives pods a service account token they may not need, stores Secrets base64-encoded rather than encrypted at rest, and permits containers to run as root. Every one of those defaults is a decision you have to revisit.

What is the single most important Kubernetes security setting?

There isn’t one, but least-privilege RBAC comes closest: most cluster compromises escalate through an over-permissioned service account or a token mounted into a pod that didn’t need API access at all. Turn off automounted tokens and scope roles to what each workload actually does.

Do I need network policies on a single-node cluster?

Yes, if more than one workload runs on it. Network policies stop an exploited service from reaching your database, cloud metadata endpoint, or the kubelet. Without them, one compromised container can talk to every other pod. See What Is a Kubernetes Network Policy?.

Are Kubernetes Secrets encrypted?

Not by default. A Secret is base64-encoded, which is reversible and offers no confidentiality. Enable encryption at rest for the API database, restrict who can read Secrets, and ideally use an external secrets manager rather than storing plaintext values in the cluster.

How do I stop an AI-generated container from running as root?

Set a securityContext on the pod and container: runAsNonRoot: true, a fixed numeric runAsUser, allowPrivilegeEscalation: false, drop all capabilities, and readOnlyRootFilesystem: true. Also make sure the image itself has a non-root user, since the runtime defaults to whatever the Dockerfile set.

Related topics

• The Kubernetes Security Checklist for AI-Built Clusters
• What Is Kubernetes RBAC (and What Did Your AI Grant Away)?
• What Is a Kubernetes Network Policy?
• Are Kubernetes Secrets Actually Secret?
• Kubernetes Pod Security: Why Your AI’s Container Runs as Root
• Kubernetes for AI Builders: Run What Your Assistant Generates Without Wrecking Production
• k3s for Vibecoders: Kubernetes on One Cheap Server, Without the Cloud Bill
• What Is a Software Supply Chain Attack?

Sources

• Kubernetes documentation — Security
• NSA/CISA Kubernetes Hardening Guidance
• OWASP Kubernetes Security Cheat Sheet
• Pod Security Standards