Kubernetes security: supply chain, RBAC, and runtime — the cluster is the estate

Kubernetes security spans supply chain, cluster configuration, identity, workload isolation, secrets, network policy, runtime behavior, and recovery. CIS benchmarks are a useful baseline, but they do not fully answer whether your workloads can be trusted, whether access is least privilege, or whether incidents can be contained.

RBAC is central. Users, groups, service accounts, CI systems, controllers, and operators should have only the permissions they need. Workload identity should avoid long-lived cloud keys where possible. Admission controls should prevent known-bad patterns before they run, not merely alert after deployment.

Container security begins before Kubernetes. Base images, dependencies, build pipelines, registries, signatures, SBOMs, vulnerability management, and deployment tags determine what enters the cluster. Runtime controls then watch for privilege escalation, unexpected network behavior, host access, crypto miners, and other signs that prevention was not enough.

The checklist cannot decide your cluster tenancy model. A shared multi-tenant cluster, per-environment clusters, regulated-workload cluster, and ephemeral preview cluster have different isolation and operational needs. Teams must decide where namespaces are enough and where separate clusters, accounts, or projects are warranted.

It also cannot decide the right admission policy posture. Blocking privileged containers, hostPath mounts, root users, mutable tags, unsigned images, or public registries may be obvious for production but disruptive in development. The organization must define phased enforcement, exceptions, and ownership.

The checklist cannot choose acceptable residual risk for third-party controllers and DaemonSets. Service meshes, monitoring agents, backup tools, security sensors, and storage drivers often require elevated permissions. Platform owners need to validate necessity, vendor trust, update cadence, and blast radius rather than approving every helm chart.

RBAC drift is a leading failure. A wide Google Group or IdP group receives cluster-admin because it was convenient during migration, and nobody revisits it. CI tokens, break-glass users, and vendor support accounts accumulate power until a single credential can change the entire cluster.

Secrets and images create preventable exposure. Teams commit Kubernetes secrets, environment files, or helm values to Git; store long-lived cloud keys in pods; pull public images by mutable latest tags; or use registries without signing and provenance checks. The deployment works, but trust is missing.

Privileged workloads are another recurring pitfall. DaemonSets run privileged with host access, containers allow escalation, default service accounts have tokens, and network policies are absent or unenforced. During an incident, teams discover they cannot isolate a namespace, identify the image digest, or restore cluster state confidently.

Start by mapping clusters, namespaces, workloads, identities, registries, CI paths, secrets stores, ingress points, and privileged components. Decide which clusters are production, regulated, shared, or experimental. Then use the checklist to verify hardening, RBAC, admission, supply-chain, secrets, runtime, and recovery controls.

Attach evidence for every checklist item. Useful artifacts include RBAC exports, group membership reviews, admission policies, pod-security settings, image-signing rules, vulnerability scan reports, registry configuration, secret-management design, network policies, audit logs, runtime alerts, backup tests, and incident runbooks.

Use the checklist before production launch, after cluster upgrades, when onboarding platform add-ons, and after major CI/CD changes. The guide helps decide what matters for your environment; the checklist makes the implementation auditable and helps keep convenience from becoming permanent cluster risk.