Is Your Organization Updated With The Best Practices of Kubernetes Security?

Kubernetes is an open-source container orchestration platform that automates deployment, scaling, and management of containerized applications. It introduces a complex attack surface that does not exist in traditional application deployments: container breakout, lateral movement between pods through permissive network policies, privilege escalation through misconfigured RBAC, and exposure of Secrets through unencrypted etcd storage. Organizations using Kubernetes to deploy applications must implement security controls across five domains: pod security hardening, network separation, authentication and authorization, audit logging, and ongoing patch management. The recommended starting point: enable RBAC with least-privilege role definitions, configure etcd encryption at rest, apply Pod Security Standards at the Restricted level for all workloads that do not require elevated privileges, implement network policies to isolate namespaces, and enable audit logging.

Quick Answer: What Are the Kubernetes Security Best Practices?

Kubernetes security is not a single control but a set of hardening decisions across the cluster architecture. The NSA/CISA Kubernetes Hardening Guide and CIS Kubernetes Benchmark both organize controls around the same five domains: pod security (running containers as non-root, immutable file systems, image scanning, Pod Security Standards); network separation (network policies isolating namespaces, TLS for all control plane communication, firewall rules around the control plane); authentication and authorization (RBAC with least-privilege roles, strong user authentication, disabled anonymous access); audit logging (enable audit logging, persist logs, configure metrics logging); and patch management (apply security updates promptly, conduct vulnerability scans, remove unused components). Encryption controls cross-cut these domains: etcd encryption at rest, TLS between cluster components, and Secrets management through a KMS-integrated external secrets store.

Kubernetes Architecture: What Needs to Be Secured

A Kubernetes cluster consists of a control plane and one or more worker nodes. Understanding what each component does determines what needs to be secured:

Control plane components (Master Node):

• API Server: the central component that exposes the Kubernetes API and serves as the gateway for all cluster interactions. All kubectl commands, controller actions, and node communications pass through the API server. It enforces authentication and authorization; misconfigured RBAC or enabled anonymous access on the API server is the highest-impact misconfiguration in Kubernetes security.
• etcd: a distributed key-value store that holds all cluster state and configuration data, including Kubernetes Secrets. Etcd is the highest-value target in a Kubernetes cluster: read access to etcd provides access to all Secrets, all configuration, and all cluster state. Etcd must be protected with TLS for all communication and encryption at rest for all data.
• Controller Manager: manages controllers that maintain the desired cluster state. Should be configured with TLS client authentication and should not have unnecessary permissions.
• Scheduler: assigns pods to nodes based on resource availability. Security policies can influence scheduling decisions to prevent privileged workloads from running on sensitive nodes.

Worker node components:

• Kubelet: the agent on each node that communicates with the API server and manages container lifecycle. Kubelet exposes an HTTP API; if not secured with authentication and TLS, it can be exploited to gain control of all pods on the node.
• Kube-Proxy: manages network routing to pods. Network policies are enforced through network plugins that interact with kube-proxy rules.
• Container Runtime: the software running containers (containerd, CRI-O). Should be secured to prevent container escapes and should be kept updated.

Kubernetes Threat Model

Attack vector	How it works	Primary hardening control
Container breakout	Attacker exploits a container runtime vulnerability or misconfiguration (such as privileged container or host path mount) to escape the container sandbox and access the host node	Pod Security Standards (Restricted); non-root containers; immutable file systems; drop all Linux capabilities except required ones
API server exploitation	Attacker exploits unauthenticated API access, overly permissive RBAC, or a stolen service account token to interact with the cluster API and perform destructive operations	Disable anonymous authentication; RBAC with least-privilege roles; short-lived service account tokens; firewall the API server port (6443) to authorized IPs only
etcd compromise	Attacker gains read access to etcd (directly or via the API server) and retrieves all Secrets and cluster state, including credentials for external systems	Enable etcd encryption at rest; restrict etcd access to the API server only via network firewall; use TLS for all etcd communication with client certificate authentication
Lateral movement via permissive network policies	Attacker who compromises one pod uses the default allow-all network behavior to communicate with other pods and services across namespaces	Network policies with default-deny baseline; namespace isolation; service mesh with mTLS for pod-to-pod communication
Privilege escalation via RBAC	Attacker with a service account that has excessive permissions uses those permissions to create new privileged pods, modify ClusterRoleBindings, or exfiltrate Secrets	Audit RBAC for cluster-admin bindings and wildcard permissions; eliminate unnecessary ClusterRole assignments; use namespace-scoped Roles rather than ClusterRoles where possible
Secret exfiltration	Attacker reads Kubernetes Secrets that are stored unencrypted in etcd or mounted as environment variables in compromised pods	Encrypt etcd at rest; restrict Secret access via RBAC; mount secrets as files rather than environment variables; consider external secrets manager with KMS integration
Supply chain attack via container image	Attacker injects malicious code into a container image that is pulled and run in the cluster	Image scanning in CI/CD pipeline; admission controller that blocks images not signed by trusted registry; use minimal base images from verified sources

Pod Security Hardening

Pods are the smallest deployable unit in Kubernetes and are often the initial execution environment when an attacker exploits a container. Pod security hardening makes exploitation harder and limits what an attacker can do after gaining code execution in a container.

1. Run containers as non-root users: configure containers to run as a specific non-root UID in the Dockerfile (USER directive) and enforce this with Pod Security Standards. Many container images default to running as root even when the application does not need root privileges. A container compromise with a non-root user has significantly reduced ability to affect the host or other system components.
2. Use immutable container file systems: set readOnlyRootFilesystem: true in the container security context. An attacker who gains execution inside a container cannot create files, download scripts, or modify application binaries. Mount secondary writable volumes only for directories that legitimately require write access (such as log directories or tmp).
3. Apply Pod Security Standards: use the Kubernetes Pod Security Admission controller to enforce the Restricted policy for all workloads that do not specifically require elevated privileges. Restricted prevents hostPID, hostIPC, hostNetwork, privilege escalation, and running as root. Apply Baseline as an absolute minimum for all workloads.
4. Scan container images: scan all images for known CVEs and configuration issues (insecure ports, broad file permissions) as part of the CI/CD pipeline before they reach the cluster. Use an admission controller webhook that blocks deployment of images that fail scanning or are not signed by a trusted registry.
5. Drop Linux capabilities: Kubernetes allows containers to be granted specific Linux capabilities beyond the default set. Apply drop: [“ALL”] in the container security context and add back only the specific capabilities the application legitimately requires. Capabilities like CAP_SYS_ADMIN, CAP_NET_ADMIN, and CAP_SYS_PTRACE significantly increase the impact of a container compromise.

Network Separation, Encryption, and Secrets Management

1. Implement network policies with a default-deny baseline: by default, all pods in a Kubernetes cluster can communicate with all other pods. Implement a default-deny NetworkPolicy in each namespace and add explicit allow rules only for required communication paths. This prevents an attacker who compromises one pod from freely communicating with other pods, services, or the cluster API.
2. Encrypt all control plane communication with TLS: all communication between the API server, etcd, kubelet, kube-proxy, and the controller manager must use TLS with valid certificates. Configure the API server to require TLS client certificates for kubelet communication (–kubelet-client-certificate and –kubelet-client-key). Certificates for Kubernetes components should be managed with defined rotation schedules through a certificate lifecycle management process.
3. Enable etcd encryption at rest: configure the EncryptionConfiguration API resource to encrypt Secrets (and optionally other resource types) stored in etcd. Use AES-GCM with a KMS provider for key management rather than static keys, so the encryption key is not stored on the same system as the encrypted data. Without this, all Kubernetes Secrets are stored as base64-encoded plaintext in etcd.
4. Use Kubernetes Secrets correctly or replace them: store sensitive configuration data in Kubernetes Secrets rather than ConfigMaps or environment variable definitions in pod specs. Mount Secrets as files rather than environment variables (environment variables can be leaked through process inspection; file-mounted secrets are more contained). For production environments with sensitive secrets, consider an external secrets manager with a Kubernetes Secrets Store CSI driver, backed by an HSM-protected key management service.
5. Restrict access to the control plane: firewall the API server (port 6443) and etcd (port 2379) to allow access only from authorized networks and systems. The control plane should not be directly accessible from the public internet. Use a VPN or bastion host pattern for administrative access.

Authentication, Authorization, and RBAC

1. Disable anonymous authentication: set –anonymous-auth=false on the API server. Anonymous requests should never be permitted to a production cluster; all API server interactions must be authenticated.
2. Implement strong user authentication: use OIDC (OpenID Connect) integration with your organization’s identity provider for user authentication to the Kubernetes API. This enables MFA enforcement, centralized audit logging of user access, and automated revocation when users leave the organization, rather than relying on long-lived client certificates that are difficult to revoke.
3. Create least-privilege RBAC policies: define specific Roles with the minimum permissions required for each use case and bind them to specific users or service accounts through RoleBindings. Avoid using cluster-admin except for emergency bootstrap access. Regularly audit ClusterRoleBindings to identify any principals with cluster-wide administrative access. Use namespace-scoped Roles rather than ClusterRoles wherever possible.
4. Restrict service account permissions: service accounts are used by pods to authenticate to the Kubernetes API. By default, pods run with a service account that may have broader permissions than necessary. Set automountServiceAccountToken: false on pods that do not need API access, and create specific service accounts with minimal permissions for pods that do.

Audit Logging and Patch Management

1. Enable audit logging: configure the Kubernetes API server audit policy to log all sensitive API calls including Secret access, RBAC changes, and pod creation. Persist audit logs to an external system (not just to pod or node storage) to ensure availability even if a node or pod is compromised or fails.
2. Configure a metrics logger: deploy a metrics collection stack (such as Prometheus with alerting rules) to monitor cluster health, resource usage, and anomalous patterns (unusual API call volumes, unexpected pod creation, access to Secrets outside normal patterns). Audit logs provide the forensic trail; metrics and alerting provide real-time detection.
3. Apply security patches promptly: Kubernetes releases security patches through minor and patch versions. Organizations should have a defined process for testing and applying Kubernetes version updates, with a target of applying critical security patches within a defined window (typically 30 days for critical CVEs). Worker nodes should be patched or replaced with updated images regularly.
4. Conduct periodic vulnerability scans: run vulnerability scanning tools against the cluster configuration (kube-bench for CIS Benchmark compliance, Trivy or similar for image vulnerabilities) on a regular schedule. Treat scan findings as a prioritized remediation backlog rather than a one-time assessment.

Deployment Example: Production Kubernetes Cluster Hardening

A financial services organization running a production Kubernetes cluster on a managed cloud Kubernetes service implements the following baseline hardening sequence:

1. Baseline assessment: run kube-bench against the cluster to generate a CIS Benchmark compliance report. Findings are categorized by severity and organized into a remediation backlog prioritized by risk.
2. RBAC cleanup: audit all ClusterRoleBindings to identify principals with cluster-admin or wildcard permissions. Remove unnecessary cluster-admin bindings; create specific Roles for each team’s actual access requirements. Service accounts for application pods are audited and restricted to the minimum API permissions required.
3. Network policy baseline: deploy a default-deny NetworkPolicy in every namespace. Define explicit allow policies for required inter-service communication. The network policy configuration is stored in version control and reviewed before any change is applied.
4. etcd encryption: enable EncryptionConfiguration with AES-GCM and a KMS provider backed by an HSM-protected key management service. The encryption key never touches the cluster nodes. After enabling, all existing Secrets are rotated to ensure they are stored in encrypted form.
5. Pod Security Standards: apply the Restricted Pod Security Standard to all namespaces except those running privileged system workloads, which are limited to the Baseline standard. All workloads are tested for compatibility with the Restricted standard before enforcement is enabled.
6. Image signing and admission control: a custom admission webhook is deployed that blocks any pod creation using an image that is not signed by the organization’s trusted registry. The CI/CD pipeline signs images after they pass vulnerability scanning. Images from external registries are mirrored through the internal registry after scanning and signing.

Limitations of Kubernetes Security Controls

• Managed Kubernetes services limit control over the control plane: when using managed Kubernetes services, the cloud provider manages the control plane. Organizations may have limited ability to configure audit logging, API server flags, or etcd directly. Security controls must be applied at the worker node and workload level. Review the managed service’s shared responsibility model to understand what the provider secures and what remains the customer’s responsibility.
• Network policies require a compatible CNI plugin: Kubernetes NetworkPolicy objects are not enforced by Kubernetes itself but by the Container Network Interface (CNI) plugin. If the CNI plugin does not support network policies, NetworkPolicy objects are silently ignored. Verify that the CNI plugin in use (Calico, Cilium, Weave, etc.) supports and enforces NetworkPolicy before relying on them for isolation.
• Container breakout mitigations are defense in depth, not guarantees: Pod Security Standards, non-root containers, and immutable file systems reduce the probability and impact of container breakout but do not eliminate it. Kernel vulnerabilities can still enable escapes even from well-hardened containers. Defense in depth (host hardening, network segmentation, and detection) is required alongside pod-level controls.
• Kubernetes Secrets at rest encryption does not protect Secrets in memory: even with etcd encryption at rest, Secrets are decrypted when accessed by the API server and may be briefly visible in memory on the API server and on the nodes where they are mounted. Applications that handle highly sensitive data may require additional application-level encryption.

How Encryption Consulting Can Help

• Encryption Advisory Services: our Encryption Advisory Services assess your Kubernetes cluster’s encryption posture, including etcd encryption at rest configuration, TLS certificate management for control plane components, and Secrets management practices, and provide recommendations aligned to NSA/CISA guidance and CIS Kubernetes Benchmark.
• HSM as a Service: HSM as a Service provides FIPS 140-3 validated hardware-backed key management for the KMS provider protecting etcd encryption keys and for any application-level encryption keys used by workloads running in the cluster.
• CertSecure Manager: CertSecure Manager manages the lifecycle of TLS certificates used by Kubernetes control plane components, worker nodes, and service mesh configurations, including automated renewal to prevent expiry-related outages and visibility into all certificate inventory across the cluster.
• CBOM Secure: CBOM Secure discovers all cryptographic assets in your Kubernetes environment, including certificates, keys, and algorithms in use across both control plane and workload configurations, providing the inventory needed to identify gaps and plan PQC migration for long-lived cryptographic infrastructure.

Conclusion

Kubernetes security requires deliberate hardening decisions across five domains: pod security, network separation, authentication and authorization, audit logging, and patch management. The controls are well-documented in the NSA/CISA Kubernetes Hardening Guide and the CIS Kubernetes Benchmark. The common failure modes are equally well-documented: anonymous API access enabled, cluster-admin bound to service accounts, etcd running without encryption at rest, default-allow network policies leaving namespaces open to lateral movement, and image pipelines that do not verify container origin.

A well-secured Kubernetes cluster does not just protect the infrastructure; it protects the sensitive data and workloads running on it, and it supports the compliance requirements of the applications deployed within it. If your organization wants to assess the current security posture of its Kubernetes environment against established benchmarks, contact Encryption Consulting.

Frequently Asked Questions

What is Kubernetes and why does it need dedicated security practices?

Kubernetes is an open-source container orchestration platform that automates deployment, scaling, and management of containerized applications. It requires dedicated security practices because it introduces attack surfaces not present in traditional deployments: container breakout, lateral movement via permissive network policies, privilege escalation through misconfigured RBAC, and exposure of Secrets through unencrypted etcd storage.

What is RBAC in Kubernetes and how does it reduce security risk?

RBAC (Role-Based Access Control) restricts access to the Kubernetes API based on roles assigned to users and service accounts. It reduces risk by enforcing least privilege: every actor gets only the permissions their function requires. Overly permissive RBAC (cluster-admin assignments, wildcard permissions) is one of the most commonly exploited misconfigurations in Kubernetes attacks.

How should Kubernetes Secrets be managed securely?

Enable etcd encryption at rest using EncryptionConfiguration with AES-GCM and a KMS provider backed by HSM-protected key management. Restrict RBAC access to Secrets. Mount Secrets as files rather than environment variables. Consider an external secrets manager with Kubernetes Secrets Store CSI driver for production environments with sensitive credentials. Rotate Secrets regularly and immediately on suspected compromise.

What is a Kubernetes Pod Security Standard and how does it replace Pod Security Policies?

Pod Security Standards (PSS) define three policy levels (Privileged, Baseline, Restricted) enforced by the built-in Pod Security Admission controller. They replaced Pod Security Policies (PSP), which were deprecated in v1.21 and removed in v1.25. Apply the Restricted level to all workloads that do not specifically require elevated privileges.

What should be encrypted in a Kubernetes cluster?

Three categories: data in transit (TLS for all control plane communication between API server, etcd, kubelet, and controller components); data at rest (etcd encryption at rest via EncryptionConfiguration, protecting all Secrets and cluster state); and application data (application-level encryption for workloads handling sensitive data such as PII or financial records).

What is the CIS Kubernetes Benchmark and how should organizations use it?

The CIS Kubernetes Benchmark provides scored security configuration checks across all major Kubernetes security domains. Run kube-bench to automate CIS Benchmark checks against a live cluster and generate a prioritized findings list. Use it alongside the NSA/CISA Kubernetes Hardening Guide, which provides threat-oriented hardening guidance organized around the Kubernetes attack surface.