Kubernetes security is a lifecycle discipline. Effective protection combines identity, admission, workload hardening, supply-chain controls, network segmentation, Secret handling, patching, monitoring, and tested recovery.

1. Review identities and effective RBAC

Risk comes from effective authorization: broad ClusterRoleBindings, wildcard rules, unnecessary Secret access, workload-creation permissions, and privileged service-account tokens. Bind at namespace scope where possible; avoid cluster-admin and system:masters unless required; review logs, exec/attach, port-forward, Secret, and workload-creation rights; and set automountServiceAccountToken: false when a workload does not call the API. Connect reviews to data access governance.

2. Enforce Pod Security deliberately

Pod Security Standards define Privileged, Baseline, and Restricted levels. Pod Security Admission applies them through namespace-scoped enforce, warn, and audit modes. Begin with warn and audit plus tested version labels, remediate violations, review exemptions, and then enforce. Restricted does not replace workload-specific authorization, network restrictions, node isolation, or runtime defenses.

3. Validate images

Reference production images by digest or verify accepted signatures and provenance at admission. Signing establishes identity or provenance according to policy; it does not prove safety. Scanning finds known vulnerabilities visible to the scanner and advisory data. Prioritize severity, exploitability, reachability, exposure, fixes, and documented exceptions while continuing runtime monitoring and patching.

4. Test NetworkPolicy

If no NetworkPolicies select a pod, Kubernetes allows ingress and egress. Policies only work when the cluster network implementation enforces the API, and they cover supported layer-3/layer-4 traffic rather than every application-layer or identity concern. Verify the plugin, test allowed and denied paths, and inventory DNS, telemetry, identity, control-plane, update, and external dependencies before default deny. This is one part of a network security toolkit.

5. Protect control-plane transport and API data

  • Configure authenticated TLS between control-plane components and clients.
  • Restrict direct etcd access, protect certificate keys, and rotate credentials through a tested process.
  • Configure encryption at rest for Secrets and other sensitive API resources, protect keys separately, and test recovery.
  • Rewrite existing objects after enabling or rotating encryption so older values are covered.

Control-plane TLS does not protect every application data path.

6. Handle Secrets as sensitive data

Kubernetes Secret objects separate confidential values from Pod specifications, but they are not encrypted in etcd by default, and Base64 provides no confidentiality. Principals with API access—or permission to create Pods in the namespace—may gain access. Mount only needed values, prevent log and crash leakage, rotate credentials, and design applications to reload them. Consider an external store when lifecycle, hardware-backed keys, dynamic credentials, or cross-platform policy justify it.

7. Patch nodes and remain supported

Upstream maintains the three most recent minor branches, with approximately one year of patch support for modern releases. Follow the stricter lifecycle of the distribution or provider and keep an emergency path for relevant fixes. Managed-service users must verify nodes as well as the control plane; see cloud computing strategies.

CVE-2021-25741 was a high-severity kubelet vulnerability where a user able to create a container with subPath mounts could access paths outside the intended volume, including on the host. It was fixed in 1.22.2, 1.21.5, 1.20.11, and 1.19.15. The lesson is to track advisories and confirm every affected component reaches a fixed version.

8. Collect evidence and test recovery

Centralize audit, control-plane, node, workload, admission, identity, and network telemetry with appropriate access and retention. Alert on high-impact permission changes, privileged workloads, denied admission, suspicious API use, unexpected egress, and disabled controls. Rehearse backup and restoration with required encryption keys and dependencies.

Control validation checklist

ControlVerify before rolloutContinuous evidenceCommon failure
RBACEffective permissionsBinding changes and recertificationIndirect privilege through workloads or Secrets
Pod Security AdmissionWarn/audit and exemptionsDenials and violationsAssuming Restricted covers every risk
ImagesDigest/signature and scanner behaviorProvenance, findings, exceptionsTreating a signature or scan as proof
NetworkPolicyPlugin enforcement and dependenciesDenied flows and testsBreaking DNS or infrastructure
SecretsEncryption and restoreAccess logs and rotationBase64 mistaken for encryption
UpgradesSupported path and compatibilityVersions and advisory responsePatched control plane, vulnerable nodes

Assign an owner and acceptable evidence to each control, then retest after version, provider, plugin, or workload changes. No checklist guarantees security, but repeatable validation makes gaps visible and actionable.