Top 21 Kubernetes Security Best Practices in 2026

What is Kubernetes Security? 

Kubernetes security is the practice of protecting Kubernetes clusters, applications, and data from unauthorized access, misconfiguration, vulnerabilities, and attacks. It includes the controls, processes, and tools used to secure every layer of a Kubernetes environment, from the cluster infrastructure to the applications running inside it.

Here are the primary layers involved in holistic Kubernetes security:

• The control plane must be secured because it manages the entire cluster and controls access to resources. 
• Workloads require protection through proper configuration, runtime controls, and least-privilege permissions. 
• Network security helps restrict communication between services and reduces the attack surface. 
• Secrets management protects sensitive data such as API keys, tokens, and credentials. 
• Supply chain and container image security focuses on identifying vulnerabilities and preventing the deployment of untrusted images and other container dependencies.
• IaC security helps prevent insecure configurations from being introduced during deployment.

Kubernetes security best practices at a glance:

This is part of a series of articles about container security 

Why Kubernetes Security Requires a Layered Approach 

Let’s review the primary layers involved in Kubernetes security.

Control Plane Security

The Kubernetes control plane is the central management layer of a cluster. It includes components such as the API server, etcd, scheduler, and controller manager. Because the control plane controls cluster operations and access to resources, it is a primary target for attackers.

Securing the control plane starts with strong authentication and authorization. Role-based access control (RBAC) should be configured according to the principle of least privilege, ensuring users and service accounts receive only the permissions they need. Multi-factor authentication (MFA) can add another layer of protection for administrative access.

The API server should be protected with network restrictions, encryption in transit, and audit logging. Access should be limited to trusted users and systems. etcd, which stores cluster state and sensitive configuration data, should use encryption at rest and restricted access controls to prevent unauthorized data exposure.

Workload and Pod Security

Workloads and pods are where applications run, making them one of the most exposed parts of a Kubernetes environment. Misconfigured workloads can allow attackers to escalate privileges, access sensitive resources, or move laterally across a cluster.

Security begins with running containers using the least privileges necessary. Containers should avoid running as root whenever possible and should use restrictive security contexts. Capabilities that are not required should be removed to reduce the impact of a compromise.

Pod security standards help enforce secure workload configurations. These standards can prevent risky behaviors such as privileged containers, host network access, or unrestricted volume mounts. Admission controllers and policy engines can automatically validate workload configurations before deployment.

Network and Communication Security

By default, Kubernetes networking allows communication between many workloads inside a cluster. Without proper controls, an attacker who compromises one application may be able to access additional services and resources.

Network policies provide a way to restrict traffic between pods and namespaces. Organizations can define which workloads are allowed to communicate, reducing unnecessary connectivity and limiting lateral movement.

Encryption should be used for communications between services, especially when sensitive data is involved. Service meshes can help enforce mutual TLS (mTLS), ensuring that both endpoints in a connection are authenticated and traffic remains encrypted.

Secrets and Identity

Applications often require access to sensitive information such as API keys, database credentials, certificates, and access tokens. Improper handling of these secrets can lead to unauthorized access and data breaches.

Kubernetes provides a native secrets mechanism, but organizations should strengthen it with encryption at rest and strict access controls. Secrets should never be hardcoded into container images, source code repositories, or deployment manifests.

Identity management is equally important. Service accounts should be assigned only the permissions required for their specific tasks. Excessive permissions increase the potential impact of compromised workloads.

Supply Chain and Image Security

Container images form the foundation of Kubernetes workloads. Vulnerabilities or malicious code introduced during the software supply chain can affect every environment where those images are deployed.

Image security starts with using trusted base images from reputable sources. Images should be regularly scanned for known vulnerabilities before deployment and throughout their lifecycle as new vulnerabilities are discovered.

Organizations should implement image signing and verification processes to ensure only approved images are deployed. Admission controls can enforce policies that block unsigned or untrusted images from entering the cluster.

IaC and Policy Governance

Infrastructure-as-code allows organizations to define Kubernetes resources through configuration files and deployment templates. While this improves consistency and automation, it can also spread insecure configurations across multiple environments if mistakes are introduced.

IaC security focuses on identifying misconfigurations before resources are deployed. Automated scanning tools can detect issues such as overly permissive RBAC roles, public exposure of services, missing network policies, or insecure pod settings during development and CI/CD workflows.

Policy governance helps enforce security standards across clusters. Policy engines can automatically validate configurations against organizational requirements and block deployments that violate security rules.

Key Kubernetes Security Best Practices 

Kubernetes security best practices fall into the following high level categories. Below we provide detailed best practices in each category:

• Control plane and API server security: Secure cluster administration by restricting API access, enforcing least-privilege permissions, centralizing authentication, and monitoring control plane activity.
• Workload and pod security: Harden containers and pods through restrictive security settings that prevent privilege escalation, credential exposure, and insecure runtime behavior.
• Network and communication security: Limit workload communication and protect data in transit using network segmentation, encryption, and isolation of critical services.
• Secrets management: Protect credentials, tokens, and certificates through encryption, controlled access, secure storage, and automated secret management processes.
• Container image and supply chain security: Reduce software supply chain risk by validating container images, scanning for vulnerabilities, and monitoring workloads for runtime threats.
• Application security and IaC governance: Prevent insecure deployments by scanning Kubernetes configurations, enforcing policy-as-code controls, and integrating security checks into CI/CD workflows.

Control Plane and API Server Security

1. Restrict API Server Access

Restricting access to the Kubernetes API server is a foundational security practice. The API server is the central management point for the entire cluster, and unauthorized access can result in full cluster compromise. Limit access using network controls such as firewalls or private endpoints, ensuring that only trusted sources within approved networks can communicate with it. Enforce strong authentication methods, such as client certificates or identity provider integrations.

Avoid exposing the API server to the public internet whenever possible. If public exposure is necessary, implement IP allowlists, VPNs, or bastion hosts to control entry points. Regularly review and audit access logs to detect unauthorized activities targeting the API server. Minimizing exposure reduces the attack surface of the control plane.

2. Enforce Least Privilege RBAC

Role-based access control (RBAC) is a core mechanism for managing permissions within Kubernetes. Enforcing least privilege means granting users, service accounts, and applications only the permissions required to perform their tasks. This limits the impact of a compromised account or application. Regularly review RBAC policies and audit role bindings to prevent privilege creep.

Automate RBAC policy checks using tools that flag overly permissive roles or unused privileges. Avoid using cluster-admin or wildcard permissions except for required administrative purposes. Strict adherence to least privilege reduces the risk from insider threats and external attacks.

3. Integrate Third-Party Identity Providers

Integrating Kubernetes with third-party identity providers such as LDAP, Active Directory, or OAuth2 platforms enables centralized authentication and secure access management. This approach allows organizations to use existing identity and access management (IAM) policies and enforce multi-factor authentication. Centralized identity providers also simplify audit and compliance reporting, as authentication events are logged consistently.

Implementing single sign-on (SSO) with trusted identity providers reduces the risk associated with local Kubernetes credentials. It also enables granular access controls based on organizational roles or project needs. Using enterprise identity solutions strengthens security posture and reduces overhead from managing local accounts.

4. Enable Audit Logging

Audit logging in Kubernetes provides a record of API server interactions, including user actions, resource changes, and authentication events. Enabling audit logs is necessary for detecting unauthorized activities, investigating incidents, and maintaining compliance. Configure audit policies to capture high-value events such as privilege escalations, configuration changes, and failed authentication attempts.

Store logs securely and integrate them with centralized log management or SIEM solutions for analysis. Regularly review audit logs to identify patterns that indicate malicious behavior or policy violations. Audit logging supports forensic investigations and accountability.

Workload and Pod Security

5. Enforce Pod Security Standards

Enforcing pod security standards ensures that workloads adhere to defined security policies, reducing the risk of privilege escalation, container breakout, or accidental exposure of sensitive resources. Kubernetes provides pod security admission (PSA) and formerly pod security policies (PSP) to define and enforce security contexts at the namespace or cluster level. Implement baseline, restricted, or custom security profiles aligned with your risk tolerance and compliance needs.

Pod security standards may include restrictions on running as root, use of privileged containers, host networking, and access to host resources. Automating policy enforcement reduces human error and misconfiguration. Regularly review and update policies to address evolving threats and application changes.

6. Run as Non-Root

Running containers as non-root users defends against privilege escalation attacks. Many container images run processes as root by default, which can lead to serious consequences if a vulnerability is exploited. Configuring pods and containers to run as non-root users limits the impact of a breach.

Enforce this practice through Kubernetes security contexts that specify user and group IDs. Ensure that application code and container images support non-root execution and update deployment manifests accordingly. This reduces the potential impact of compromised workloads.

7. Make Root Filesystems Read-Only

Mounting root filesystems as read-only helps prevent unauthorized modifications and persistence by attackers. When a container’s root filesystem is read-only, attackers cannot alter binaries, inject scripts, or modify configuration files.

Configure the readOnlyRootFilesystem flag in pod security contexts. Ensure that applications write data only to explicitly mounted writable volumes, such as /tmp or specific data directories. Verify that workloads comply with this policy and enforce it in deployment pipelines.

8. Disable Service Account Automounts

Kubernetes automatically mounts service account tokens into every pod by default, which can expose cluster credentials unnecessarily. Disabling service account automounts for pods that do not require API access limits the risk of token theft and misuse.

Control this setting at the service account and pod level using the automountServiceAccountToken field. Grant service account tokens only to workloads that require them and review token permissions regularly.

Network and Communication Security

9. Enforce Restrictive Network Policies

Network policies allow administrators to control traffic flow between pods and external resources. Enforcing restrictive policies ensures that only necessary communications are permitted, reducing lateral movement risk. Start with a default-deny approach and explicitly allow required traffic.

Fine-grained network segmentation limits the impact of compromised workloads. Regularly review and update policies as application architectures evolve, and test policies to avoid blocking legitimate traffic.

10. Encrypt Data in Transit

Encrypting data in transit between pods, nodes, and external endpoints protects sensitive information from interception or tampering. Kubernetes supports TLS for API server communication, and service meshes like Istio or Linkerd provide mutual TLS (mTLS) for pod-to-pod traffic. Ensure that internal and external communications use strong encryption protocols and that certificates are managed securely.

Rotate encryption keys and certificates regularly. Automated certificate management tools can reduce the risk of expired or misconfigured certificates. Enforcing encryption in transit reduces the risk of man-in-the-middle attacks and data leaks.

11. Isolate etcd

etcd stores Kubernetes cluster data, including secrets and configuration details. If compromised, it can lead to full cluster takeover. Isolate etcd on a dedicated network segment, restrict access to the API server, and enforce strong authentication and TLS encryption for all communications.

Do not expose etcd to the public internet or broader internal networks. Monitor access logs and audit etcd for unauthorized access. Back up etcd data securely and test recovery procedures to maintain business continuity.

Secrets Management

12. Enable Encryption at Rest

Kubernetes secrets are stored in etcd and may be stored in plaintext without additional safeguards. Enabling encryption at rest ensures that sensitive data such as API keys, passwords, certificates, and tokens are encrypted before being written to etcd.

Configure encryption providers and define policies that cover secrets and other sensitive resources. Use strong encryption algorithms and manage encryption keys through dedicated key management systems. Rotate encryption keys regularly and verify settings after cluster upgrades or configuration changes.

13. Use External Secrets Managers

Storing secrets directly in Kubernetes can create management and security challenges. External secrets managers such as HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, or Google Secret Manager provide centralized storage, access control, auditing, and automated secret rotation. Integrating Kubernetes with these platforms reduces the need to store long-lived credentials inside the cluster.

External solutions can inject secrets into workloads when needed, minimizing exposure and simplifying credential management. Enforce strict access controls and monitor secret access activity through audit logs.

14. Mount Secrets as Files

Mounting secrets as files is generally more secure than exposing them through environment variables. Environment variables can be leaked through logs, debugging tools, process listings, or application errors. Secret volumes provide a more controlled way to access sensitive information at runtime.

Configure applications to read secrets from mounted files and restrict file permissions to required processes. Combine this approach with secret rotation mechanisms so applications can receive updated credentials.

Container Image and Supply Chain Security

Utilize Minimal Base Images

Container images should contain only the components required for the application to run. Minimal base images reduce the attack surface by eliminating unnecessary packages, libraries, and services that could contain vulnerabilities.

Use lightweight images such as Alpine Linux, distroless images, or other minimal distributions where appropriate. Review image contents and remove unused dependencies during the build process.

16. Automate Image Scanning

Container image scanning identifies vulnerabilities, outdated packages, exposed secrets, and misconfigurations before workloads reach production. Automated scanning should occur during image builds, registry storage, and deployment stages.

Integrate scanning tools into CI/CD pipelines and prevent deployment of images containing critical vulnerabilities. Regular rescanning is important because new vulnerabilities may be discovered after publication.

17. Enforce Continuous Runtime Threat Detection

Controls applied during build and deployment cannot detect every runtime threat. Continuous runtime threat detection monitors container behavior, system calls, network activity, and process execution to identify suspicious actions.

Runtime security tools should generate alerts for anomalous activity and integrate with incident response workflows. Establish baselines for expected workload behavior and monitor deviations.

Application Security and IaC Governance

18. Scan Kubernetes Manifests for Misconfigurations

Misconfigured Kubernetes manifests are a common source of vulnerabilities. Issues such as privileged containers, unrestricted network access, excessive permissions, and missing security contexts can be introduced during development. Scanning manifests helps identify these risks before production.

Use automated validation tools to analyze deployment manifests, Helm charts, and configuration files against security best practices. Integrate these checks into development workflows and define remediation processes.

19. Shift Kubernetes Security Left in CI/CD Pipelines

Shifting security left means incorporating security checks earlier in the development lifecycle rather than relying only on post-deployment controls. Embedding Kubernetes security validation into CI/CD pipelines helps detect vulnerabilities, policy violations, and configuration errors before deployment.

Security testing should include image scanning, manifest validation, secrets detection, dependency analysis, and policy compliance checks. Automated feedback allows developers to address issues quickly.

20. Enforce Policy-as-Code for Deployment Guardrails

Policy-as-code enables organizations to define security and compliance requirements as machine-readable rules enforced during deployment. Solutions such as Open Policy Agent (OPA), Gatekeeper, and Kyverno allow teams to create policies that prevent insecure configurations from entering the cluster.

Examples include blocking privileged containers, requiring resource limits, enforcing approved image registries, or restricting host path mounts. Centralized policy management promotes consistency across environments and reduces reliance on manual reviews.

21. Secure Helm Charts and Kustomize Templates

Helm charts and Kustomize templates simplify Kubernetes deployments but can introduce security risks if not maintained. Insecure default configurations, outdated dependencies, or unverified third-party templates may expose clusters to vulnerabilities. Review and validate all templates before use.

Use trusted sources for charts and dependencies, verify package signatures when available, and update templates to address newly discovered vulnerabilities. Scan templates for misconfigurations and apply organizational security policies before deployment.

Related content: Read our guide to container security best practices

How to Prioritize Kubernetes Security Improvements

Organizations typically achieve the greatest security gains by addressing Kubernetes risks in phases rather than attempting to implement every control at once. A practical approach is to first secure administrative access and core cluster infrastructure, then harden workloads and communications, followed by supply chain protections and governance controls. Advanced monitoring and detection capabilities can be added as security maturity increases.

Prioritizing Kubernetes security fixes typically involves these steps:

• Secure the control plane and RBAC first: Prioritize API server protection, patch management, audit logging, and least-privilege RBAC. Reducing excessive permissions and limiting administrative access often delivers the largest immediate reduction in risk.
• Harden workloads, secrets, and network communications: Enforce restrictive pod security settings, run containers as non-root where possible, secure secrets with encryption and access controls, and use network policies to limit lateral movement between workloads.
• Strengthen image, supply chain, and IaC security: Scan container images for vulnerabilities, verify software integrity through supply chain controls, and integrate infrastructure-as-code scanning and policy enforcement into development and deployment workflows.
• Add runtime detection and advanced protections: As security programs mature, implement runtime monitoring, centralized logging, alerting, and incident response capabilities. Additional controls such as service meshes, workload identity frameworks, and automated policy enforcement can further improve security posture.

How to Choose Kubernetes Security Solutions 

Selecting a Kubernetes security solution requires evaluating how well it protects workloads across the container lifecycle. Kubernetes environments introduce risks at multiple stages, from image creation and deployment to runtime operations. The right solution should provide broad coverage while helping teams identify and remediate issues.

• Look for end-to-end lifecycle coverage: Choose solutions that provide security controls across development, build, registry, deployment, and runtime stages.
• Prioritize deep container image scanning: Evaluate whether the solution detects vulnerabilities, outdated packages, insecure dependencies, malware, misconfigurations, and compliance issues across all image layers.
• Assess registry integration capabilities: Ensure the tool integrates with container registries and supports policy enforcement before deployment.
• Verify base image analysis and recommendations: Look for solutions that assess base images and provide guidance for selecting safer alternatives.
• Evaluate vulnerability prioritization features: The solution should prioritize vulnerabilities based on severity, impact, and runtime context.
• Ensure strong visibility and reporting: Dashboards and reporting should support risk tracking and compliance requirements.
• Check remediation support and auditability: Look for features such as status tracking, remediation guidance, and audit trails.
• Support developer workflows and shift-left security: Ensure integration with development and CI/CD processes.
• Include runtime security context: Consider solutions that provide visibility into running workloads and use runtime information for risk assessment and threat detection.
• Scale across multi-cloud and hybrid environments: Select solutions that integrate with multiple registries, cloud providers, and deployment environments while maintaining consistent policies.

Container Security with Checkmarx One 

Kubernetes security relies on robust container security that can move at the speed of AI-driven development. Checkmarx Container Security is an agentic AI-powered capability of the Checkmarx One platform that secures containerized applications from build pipelines to runtime as part of a unified, code-to-cloud AppSec program. It correlates image, pipeline, and runtime findings inside ASPM so teams can see which vulnerabilities in which workloads actually matter.

Key features include:

• Multi-layer image scanning: Checkmarx scans container images across all layers, including base images, application code, and third-party dependencies. It detects vulnerabilities, malware, misconfigurations, and license issues, helping teams catch problems before deployment.
• Runtime insights correlation: The platform correlates static scan results with runtime behavior, enabling teams to prioritize vulnerabilities based on actual exploitability and impact. This reduces alert noise and focuses remediation on risks that matter in production.
• Triage and risk prioritization: Security teams can assess vulnerabilities by severity and exploitability, manage their status by project, and act on remediation guidance. Built-in dashboards help triage issues efficiently and track progress over time.
• Base image remediation guidance: Developers receive recommendations for safer base images, helping to reduce risk at the foundation of containerized workloads and ensure more secure build pipelines.
• Integrated CI/CD and developer tooling: The solution integrates into CI/CD workflows and developer environments, including support for Docker extensions. Developers get real-time feedback and early detection of issues, enabling faster fixes without disrupting delivery velocity.
• Agentic AI assistance across the SDLC: Developer Assist flags risky base images and Dockerfile/Kubernetes misconfigs in the IDE; Policy Assist enforces container policies in CI/CD; Insights Assist rolls container risk into ASPM posture views. 
• Runtime-aware prioritization (Sysdig): prioritize the subset of vulnerabilities actually loaded/used at runtime to reduce noise and focus on exploitable risk.
• Unified code-to-cloud correlation: connect container findings with SAST/SCA/IaC/API/DAST to understand which vulnerabilities in which workloads matter.
• Enhanced visibility and reporting: Checkmarx provides detailed reporting and audit trails, giving security teams a clear view into container risks. Customizable severity analysis and compliance tracking help organizations meet regulatory and internal standards more effectively.

By combining static and dynamic insights, Checkmarx ONE helps teams secure containerized applications throughout development and production, empowering developers and security teams to collaborate on reducing risk at scale.

Learn more about Checkmarx One for container security