Kubernetes Security Hardening

Kubernetes attack surface overview

Kubernetes has a large attack surface. It is a distributed system with many components that expose APIs, store sensitive data, and make authorization decisions.

The API server is the front door. Every interaction with the cluster goes through it. A misconfigured API server with anonymous authentication enabled or overly broad RBAC rules gives attackers direct control. The 2023 OWASP Kubernetes Top 10 lists insecure workload configurations and overly permissive RBAC as the top two risks.

etcd stores all cluster state, including secrets. Direct access to etcd means access to every secret in the cluster. It must be encrypted at rest and accessible only to the API server.

Kubelet runs on every node and executes pod workloads. An exposed kubelet API (port 10250) without authentication lets attackers list pods, exec into containers, and exfiltrate data. The Tesla cryptojacking incident in 2018 exploited an unauthenticated kubelet dashboard.

Container runtime (containerd, CRI-O) manages container lifecycle. Container escape vulnerabilities like CVE-2024-21626 (runc “Leaky Vessel”) allow processes inside a container to break out to the host. Assume escapes will happen and limit the blast radius.

The network layer is flat by default. Without network policies, every pod can talk to every other pod. A compromised application pod can reach the database pod, the secrets store, and the control plane.

CIS Kubernetes Benchmark essentials

The CIS Kubernetes Benchmark contains 200+ recommendations organized by component. Not all of them matter equally. Here is what to prioritize.

Control plane hardening

Disable anonymous authentication on the API server (--anonymous-auth=false). Enable audit logging. Restrict access to the etcd datastore. On managed Kubernetes (EKS, GKE, AKS), the cloud provider handles most control plane hardening, but you are still responsible for RBAC, pod security, and workload configuration.

What to prioritize first

The highest-impact CIS recommendations:

• RBAC enabled and configured (CIS 5.1.x): Default deny, explicit grants
• Pod security standards enforced (CIS 5.2.x): No privileged containers, no host networking
• Network policies applied (CIS 5.3.x): Restrict pod-to-pod traffic
• Secrets encrypted at rest (CIS 1.2.x): Encrypt etcd or use an external KMS
• Audit logging enabled (CIS 3.2.x): Record API server access for forensics

Automated scanning

kube-bench runs CIS Benchmark checks against your cluster configuration. It checks kubelet flags, API server settings, and etcd configuration. Works for self-managed clusters. Limited use on managed clusters where you do not control the control plane.

Kubescape covers CIS Benchmarks plus NSA-CISA guidelines and MITRE ATT&CK mappings. It scans both cluster configuration and workload manifests, so the coverage is broader than kube-bench. CNCF incubating project with 11,200+ GitHub stars.

Trivy can scan running Kubernetes clusters (trivy k8s --report summary cluster) in addition to manifests. Good for teams already using Trivy for image and IaC scanning.

Checkov scans Kubernetes YAML and Helm charts with 500+ Kubernetes-specific policies. Works well for pre-deployment manifest scanning in CI/CD. See our Checkov vs KICS comparison for differences between IaC scanning tools.

RBAC done right

Kubernetes RBAC (Role-Based Access Control) controls who can do what in the cluster. The default configuration is too permissive for production.

Least privilege principles

Grant only the permissions a user or service account actually needs. Avoid ClusterRole bindings when a namespaced Role binding is sufficient. Never bind cluster-admin to service accounts unless there is a documented, reviewed reason.

A common mistake: leaving the default service account in every namespace with broad permissions. Every pod that does not specify a service account uses the default one. If that default account has permissions to list secrets or create pods, any compromised workload inherits those permissions.

Namespace isolation

Use namespaces to separate teams, environments, and applications. Combine namespaces with RBAC so that team A cannot access team B’s resources. A developer working on the payment service should not have access to the user-data namespace.

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: payment-team-access
  namespace: payment-service
subjects:
  - kind: Group
    name: payment-team
    apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: developer
  apiGroup: rbac.authorization.k8s.io

Service account hygiene

Create dedicated service accounts for each workload. Set automountServiceAccountToken: false on pods that do not need API access. Token volumes are auto-mounted by default, giving every pod a credential to the API server whether it needs one or not.

Auditing RBAC

Review RBAC configurations regularly. Look for ClusterRoleBindings to cluster-admin, wildcards in Role rules (verbs: ["*"], resources: ["*"]), and service accounts with more permissions than their workload requires. Tools like rbac-audit and kubectl-who-can help identify overly permissive rules.

Pod security standards and admission controllers

Pod Security Standards (PSS) replaced the deprecated PodSecurityPolicy in Kubernetes 1.25. They define three levels of restriction.

The three profiles

Privileged: No restrictions. Only for system-level workloads like CNI plugins and storage drivers that genuinely need host access.

Baseline: Blocks known privilege escalation vectors. Prevents hostNetwork, hostPID, hostIPC, privileged containers, and most hostPath mounts. This is the minimum for any production namespace.

Restricted: Adds further hardening. Requires non-root users, drops all Linux capabilities, requires read-only root filesystems, and mandates seccomp profiles. Target this for application workloads.

Enforcement

Apply PSS at the namespace level using labels:

apiVersion: v1
kind: Namespace
metadata:
  name: production
  labels:
    pod-security.kubernetes.io/enforce: restricted
    pod-security.kubernetes.io/warn: restricted
    pod-security.kubernetes.io/audit: restricted

Use warn mode first to identify pods that would be blocked, then switch to enforce after fixing violations.

OPA Gatekeeper and Kyverno

For policies beyond what PSS covers, use a policy engine. OPA Gatekeeper uses Rego policies and ConstraintTemplates. Kyverno uses native Kubernetes YAML policies. Both can enforce custom rules: required labels, allowed registries, resource limits, and anything else you can express as a policy.

Kyverno is easier to adopt for teams without Rego experience. Gatekeeper is more powerful for complex policy logic.

Network policies for micro-segmentation

Default Kubernetes networking is fully open. Every pod can reach every other pod and every external endpoint. Network policies restrict that.

Default deny

Start with a default-deny policy in every namespace. This blocks all ingress and egress traffic unless explicitly allowed:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
  namespace: production
spec:
  podSelector: {}
  policyTypes:
    - Ingress
    - Egress

Then add specific allow rules for known traffic patterns. The frontend pod can reach the API pod. The API pod can reach the database pod. The database pod can reach nothing except DNS.

CNI requirements

Network policies only work if your CNI plugin supports them. Calico, Cilium, Antrea, and Weave Net support network policies. The default kubenet and some basic Flannel configurations do not. Verify your CNI before relying on network policies.

Cilium adds Layer 7 (HTTP/gRPC) policy enforcement, so you can restrict traffic by URL path or gRPC method in addition to IP and port. This is useful for service-to-service authorization within a service mesh.

DNS egress

When you set default-deny egress, you break DNS resolution. Every pod needs access to the cluster DNS service (usually CoreDNS in kube-system). Add an explicit egress rule allowing UDP/TCP port 53 to the DNS service.

Secret management

Kubernetes secrets are base64-encoded by default, not encrypted. Anyone with RBAC access to read secrets in a namespace can decode them trivially.

External secrets managers

The production approach is to store secrets outside Kubernetes and inject them at runtime.

HashiCorp Vault is the most widely used external secrets manager. The Vault Agent Sidecar Injector or the CSI Secrets Store Driver can inject Vault secrets into pods without application changes. Vault handles encryption, rotation, audit logging, and dynamic secrets (temporary credentials generated on demand).

AWS Secrets Manager, GCP Secret Manager, Azure Key Vault are cloud-native options. The External Secrets Operator syncs secrets from these services into Kubernetes Secret objects. Simpler than Vault if you are single-cloud.

Sealed Secrets (from Bitnami) encrypts secrets with a cluster-specific key so they can be safely stored in Git. The controller in the cluster decrypts them at deploy time. Good for GitOps workflows where you want secrets versioned alongside infrastructure.

etcd encryption

If you keep secrets in native Kubernetes secrets (many teams do for non-critical configuration), enable encryption at rest for etcd. On EKS, this is enabled by default using AWS KMS. On GKE, use Application-Layer Secrets Encryption with Cloud KMS. Self-managed clusters need to configure an EncryptionConfiguration resource.

Runtime monitoring and threat detection

Static scanning catches known issues before deployment. Runtime monitoring catches active threats in production.

Falco

Falco is the CNCF incubating project for runtime threat detection. It hooks into the Linux kernel (via eBPF or a kernel module) and watches system calls in real time. Default rules detect shell spawns inside containers, sensitive file reads, outbound network connections to unusual destinations, and privilege escalation attempts.

Falco generates alerts, not blocks. Pair it with a response system (Falco Sidekick, SIEM integration, or PagerDuty) to act on detections.

Sysdig Secure

The commercial platform built on top of Falco. Adds a managed rule set, compliance dashboards, forensics, and response automation. A good fit for teams that want the Falco detection engine with enterprise support and a UI on top.

KubeArmor

An eBPF-based runtime security engine that can enforce policies (not just detect). It can restrict file access, process execution, and network connections at the pod level. Useful as an additional enforcement layer beyond network policies.

What to monitor

Priority detection rules for any runtime monitoring setup:

• Shell processes started inside containers (/bin/sh, /bin/bash)
• Outbound connections to cryptocurrency mining pools
• Reads of /etc/shadow, /etc/passwd, or Kubernetes service account tokens
• Process execution from unexpected directories (/tmp, /dev/shm)
• Container escape indicators (mount namespace changes, cgroup escapes)

Auditing and compliance

Kubernetes audit logging records every request to the API server. This is your forensic trail when something goes wrong.

Audit policy configuration

Configure the API server audit policy to log at the Metadata level for most resources and Request level for sensitive operations (secrets, RBAC changes, pod exec). The RequestResponse level captures full request and response bodies but generates large volumes of data. Use it selectively.

Ship audit logs to a centralized logging system (Elasticsearch, Splunk, CloudWatch, Datadog) where they are tamper-proof and searchable.

Compliance frameworks

CIS Kubernetes Benchmark maps to broader compliance requirements:

• SOC 2 Type II: RBAC, audit logging, encryption at rest, network segmentation
• PCI DSS: Network isolation (network policies), access control (RBAC), logging, vulnerability management (image scanning)
• HIPAA: Encryption in transit and at rest, access controls, audit trails
• FedRAMP: CIS Benchmark compliance plus continuous monitoring

Kubescape maps findings to NSA-CISA and MITRE ATT&CK frameworks. Checkov maps to CIS and custom compliance frameworks. Trivy includes CIS Benchmark scanning for Kubernetes.

Continuous compliance

Run compliance scans on a schedule, not just during audits. Weekly scans with trending reports show auditors that you maintain compliance continuously, not just at point-in-time assessments. Integrate scan results into your SIEM or compliance dashboard.

FAQ

For broader cloud security topics, see our Cloud Infrastructure Security hub and What is CNAPP.

Frequently Asked Questions

Written by

Suphi Cankurt

Suphi Cankurt is an application security enthusiast based in Helsinki, Finland. He reviews and compares 129 AppSec tools across 10 categories on AppSec Santa. Learn more.