Kubernetes Security Principles

Overview

This page establishes the authoritative, provider-neutral security principles for managed Kubernetes services. Scope is limited to managed control-plane offerings: Google Kubernetes Engine (GKE), Amazon Elastic Kubernetes Service (EKS), Azure Kubernetes Service (AKS), and Oracle Container Engine for Kubernetes (OKE). Self-managed Kubernetes (kubeadm, k3s, k0s), on-premises deployments, and container runtimes below the cluster API are explicitly out of scope.

This page does not contain provider-specific controls or CLI commands. For provider controls, see the provider pages: GCP GKE Hardening (live — Phase 16 pilot); AWS EKS Hardening, Azure AKS Hardening, and OCI OKE Hardening arrive in Phase 17. The principles on this page apply uniformly across all four providers; the provider pages translate each principle into auditable configurations, CLI commands, and IaC.

Before reading the provider Kubernetes pages, security engineers should be familiar with the three foundational cross-cutting domains: Identity and Access Management (RBAC underpins all Kubernetes access control), Network Security (network policy foundations, private cluster design), and Logging and Monitoring (audit log patterns, immutable log sinks). Kubernetes hardening extends these foundations — it does not replace them.

Threat Model

The Kubernetes control plane is the primary attack entry point. Compromise of the kube-apiserver grants arbitrary cluster access: any authenticated principal — or an unauthenticated one if anonymous authentication is enabled — can enumerate secrets, create privileged pods, or modify workloads. Lateral movement from any compromised pod is the primary blast-radius amplifier: a single pod with an overly-permissive service-account token or a privileged security context can pivot to the underlying node, then to the cloud provider metadata service, and from there to broader cloud credentials. The nine threat categories below represent the principal attack paths observed in production cluster incidents.

Cluster-Baseline Principles

These 8 principles form the minimum acceptable security baseline for any managed Kubernetes cluster regardless of provider. Provider pages in this guide map each principle to auditable controls and CLI commands.

1. Defense-in-depth. No single control is sufficient. Kubernetes security requires layered controls: network isolation at the cluster perimeter, admission enforcement at the API boundary, Pod Security Standards at the workload level, and audit logging for detection. Each layer independently limits blast radius when another layer fails. Design assuming any single control will eventually be bypassed.

2. Least-privileged RBAC. Namespace-scoped Role objects are preferred over ClusterRole objects. No production workload should carry wildcard verbs (*) or wildcard resources (*). Service accounts should be provisioned per-workload, not shared across deployments. Audit ClusterRoleBinding objects regularly; any binding to cluster-admin requires documented business justification.

3. Pod Security Standards (PSS). The built-in PodSecurity admission controller enforces three profiles: Privileged (no restrictions), Baseline (prevents known privilege escalations), and Restricted (heavily restricted, follows current hardening best practices). The restricted profile is the target for all new workloads; baseline is the floor for legacy workloads that cannot yet meet restricted requirements. Enforce via namespace label: pod-security.kubernetes.io/enforce: restricted.

4. Network policy default-deny. All ingress and egress for every namespace should be denied by default using a NetworkPolicy with an empty pod selector and an empty ingress/egress block. Allow rules are then added explicitly for required communication paths. This requires a NetworkPolicy-capable CNI (Calico, Cilium, or a provider-managed equivalent such as GKE Dataplane V2). A cluster without network policies has a flat pod network where any compromised pod can reach any other workload.

5. Encryption at rest for etcd. All Kubernetes Secrets, ConfigMaps, and other sensitive resources stored in etcd must be encrypted at rest using a customer-managed key (CMK) via the cloud provider's key management service (KMS). Managed Kubernetes offerings provide envelope encryption: the data encryption key (DEK) is encrypted by the CMK; rotation of the CMK triggers re-encryption of DEKs. Encryption at rest limits the impact of direct etcd access or backup media compromise.

6. Audit logging. Kubernetes audit log and control-plane component logs (API server, scheduler, controller-manager) must be collected to an immutable log sink before any workload runs on the cluster. Audit logs are the primary forensic record for incident response. Disabling or not enabling audit logging eliminates the ability to determine what happened during or after a breach. Many compliance frameworks mandate audit log retention of 12–36 months.

7. Immutable infrastructure. Node operating systems should be immutable: read-only root filesystems, no in-place package updates, and nodes replaced rather than patched. Provider-managed hardened images provide this property: Bottlerocket (AWS), Container-Optimized OS (GCP), Azure Linux (formerly CBL-Mariner), and Oracle Linux 8 minimal (OCI). Immutable nodes prevent persistence mechanisms that rely on writing to the host filesystem or installing packages post-boot.

8. Ephemeral credentials. No static key files or long-lived service account JSON credentials should be mounted into pods. Workload identity provides short-lived, automatically-rotated credentials bound to a Kubernetes service account: EKS Pod Identity (AWS), Workload Identity Federation for GKE (GCP), AKS Workload Identity (Azure), and OKE Workload Identity (OCI). Ephemeral credentials limit the window of opportunity for credential theft and eliminate the need for secret rotation procedures.

Common Misconfigurations

These 7 patterns are commonly observed in production clusters and each represents a significant security control gap. Gate G16.3 validates that all 7 patterns are documented here.

1. kubelet --anonymous-auth=true

Enabling --anonymous-auth=true on the kubelet exposes port 10250 to unauthenticated exec, log, and metrics operations. Any network-reachable attacker can run arbitrary commands on the node without authentication. This configuration is the default on older Kubernetes versions and some managed offerings if not explicitly hardened.

Remediation: Set --anonymous-auth=false with explicit authentication mode Webhook. Verify with kubectl get --raw /api/v1/nodes/NODE/proxy/configz.

2. Default service-account token automount (automountServiceAccountToken)

Kubernetes automatically mounts a service-account token (automountServiceAccountToken: true by default) into every pod, including pods that never call the Kubernetes API. An attacker who compromises any pod inherits that token's RBAC permissions. In clusters where service accounts have broad permissions, this is a direct privilege escalation path.

Remediation: Set automountServiceAccountToken: false in the pod spec or ServiceAccount object for workloads that do not need cluster API access. Opt-in explicitly for workloads that do.

3. Wildcard RBAC permissions

ClusterRoles with verbs: ["*"] or resources: ["*"] are cluster-admin equivalents by another name. A single compromised workload with wildcard RBAC can read all Secrets, create privileged pods, or delete critical namespaces. Wildcard grants are frequently introduced by operators, Helm charts, and service mesh installations that over-provision permissions for convenience.

Remediation: Enumerate specific verbs and resources; prefer namespace-scoped Roles over ClusterRoles. Audit with kubectl auth can-i --list --as system:serviceaccount:NAMESPACE:NAME.

4. Privileged pods without PSS enforcement

Running pods with securityContext.privileged: true, hostPID: true, hostNetwork: true, or hostPath: / mounts grants container-escape capability. Without Pod Security Standards enforcement at the namespace level, any workload can request these capabilities and there is no admission gate blocking them.

Remediation: Enforce PSS Restricted or Baseline profile at namespace level; require documented justification for any namespace using the Privileged profile. Apply the label pod-security.kubernetes.io/enforce: restricted.

5. Public API endpoint without IP allow-list

Exposing the kube-apiserver on a public endpoint without an IP allow-list means any credential leak — service account token, kubeconfig, or CI/CD secret — is immediately exploitable from the internet. A public API endpoint without access restrictions is the number-one Kubernetes breach vector in cloud environments. Attackers continuously scan for exposed kube-apiservers on port 6443.

Remediation: Enable private cluster mode (no public API endpoint) or, at minimum, restrict the public endpoint to specific authorized CIDR ranges before placing any workload on the cluster.

6. docker.sock or sensitive hostPath mounts in untrusted pods

Mounting the Docker socket (docker.sock) or sensitive hostPath volumes (/, /etc, /var/run) into containers grants the container full host access. Containers with these mounts can escape isolation entirely, read host credentials, install persistent backdoors, or pivot to other nodes. This pattern is commonly introduced by CI/CD tooling and monitoring agents.

Remediation: Deny docker.sock and sensitive hostPath mounts via PSS Restricted profile or an admission webhook. Audit existing workloads: kubectl get pods -A -o json | jq '.items[].spec.volumes[]?'.

7. Disabled audit logging

Disabling Kubernetes audit log or control-plane log collection eliminates forensic capability. Without audit logs, there is no way to determine what happened during or after an incident — which credentials were used, which resources were accessed, and what changes were made. Many compliance frameworks (SOC 2, PCI DSS, ISO 27001) require audit log retention. The absence of audit logging frequently turns a containable incident into an unresolvable one.

Remediation: Enable audit log and control-plane log collection to an immutable log sink before placing any workload on the cluster. Verify that log forwarding is active, not just enabled.

Compliance Framework Reference

The following compliance frameworks provide specific Kubernetes hardening guidance. Provider pages in this guide map each control to applicable sections in the frameworks below.

Note: A new major CIS Kubernetes upstream benchmark was released May 2026. Sub-control IDs in that newer version are unverified at time of writing. This guide uses CIS Kubernetes Benchmark v1.11.0 as the authoring pin — the stable version with verified kube-bench tooling support.

kube-bench (v0.13.0+, --benchmark cis-1.11 flag) is the authoritative automated tool for CIS Kubernetes Benchmark v1.11.0 assessment. Source: github.com/aquasecurity/kube-bench (accessed 2026-05).

Deprecated Technology Warnings

These technologies were widely recommended in earlier Kubernetes documentation but have been deprecated, removed, or superseded. References to them as current recommendations indicate stale content.

Reading the Provider Pages

Each provider Kubernetes page in this guide contains a set of auditable hardening controls. Each control is structured as an <article class="control-box"> element with the following components: a control ID (e.g., gcp-k8s-01), a severity rating (CRITICAL, HIGH, or MEDIUM), a control type (configuration, IAM, network, logging), and a threat model reference mapping the control to the applicable threat category from the Threat Model section above.

Each control includes: a CLI remediation block (provider CLI commands to audit and remediate the control), a Terraform IaC block (infrastructure-as-code to provision the control correctly), and an 11-column compliance table mapping the control to applicable framework sections. The 11 compliance columns are: Control / Severity / Type / Provider (4 metadata columns) followed by CIS Kubernetes Benchmark v1.11.0, the provider-specific CIS managed-service benchmark, NIST SP 800-53 rev5, ISO/IEC 27001:2022, ISO/IEC 27017:2015, NIST SP 800-190 (Sep 2017), and NSA/CISA Kubernetes Hardening Guide v1.2.

For GKE controls, any control that behaves differently between GKE Autopilot and GKE Standard clusters includes a callout-info block immediately after the control header, explaining the default behaviour and required configuration for each cluster mode. CIS GKE Autopilot Benchmark v1.3.0 documents Autopilot-specific defaults.

For provider-specific Kubernetes hardening guides, see AWS EKS, Azure AKS, GCP GKE, and OCI OKE.

Sources

1. CIS Kubernetes Benchmark v1.11.0. Center for Internet Security. cisecurity.org/benchmark/kubernetes (accessed 2026-05).
2. NSA/CISA Kubernetes Hardening Guide v1.2. National Security Agency / CISA. Aug 2022. media.defense.gov (PDF) (accessed 2026-05).
3. NIST SP 800-190: Application Container Security Guide. National Institute of Standards and Technology. Sep 2017. csrc.nist.gov/publications/detail/sp/800-190/final (accessed 2026-05).
4. CVE-2025-1974 IngressNightmare. Kubernetes Blog. Mar 2025. kubernetes.io/blog/2025/03/24/ingress-nginx-cve-2025-1974/ (accessed 2026-05).
5. kube-bench: automated assessment tool for CIS Kubernetes Benchmark v1.11.0. Aqua Security. github.com/aquasecurity/kube-bench (accessed 2026-05).
6. Kubernetes Pod Security Standards. kubernetes.io. kubernetes.io/docs/concepts/security/pod-security-standards/ (accessed 2026-05).
7. GKE Security Overview. Google Cloud. cloud.google.com/kubernetes-engine/docs/concepts/security-overview (accessed 2026-05).
8. Kubernetes Audit Logging. kubernetes.io. kubernetes.io/docs/tasks/debug/debug-cluster/audit/ (accessed 2026-05).