# Kubernetes security: 6 key risks and 10 best practices **URL:** https://mazehq.com/learn/kubernetes-security **Date:** 2026-10-15 ## What is Kubernetes security? Kubernetes security is the practice of protecting containerized applications, cluster infrastructure, and data through a layered defense model. It spans the **4 Cs of cloud-native security**: Code, Container, Cluster, and Cloud. Securing a deployment requires hardening access control, isolating networks, and managing workload privileges. **Kubernetes security best practices include:** - **Keep Kubernetes and cluster components updated:** Patch Kubernetes, node operating systems, runtimes, and add-ons regularly to reduce exposure to known vulnerabilities. - **Implement Kubernetes RBAC:** Grant users and service accounts only the permissions required for their roles, avoiding broad or cluster-admin access. - **Enforce pod security standards:** Block privileged containers, host access, unnecessary capabilities, and other unsafe workload configurations. - **Use Kubernetes network policies:** Restrict pod-to-pod and outbound communication to only the connections required by each workload. - **Encrypt Kubernetes secrets:** Protect secrets in etcd with encryption at rest and tightly restrict access through RBAC or external secret managers. - **Scan container images for vulnerabilities:** Integrate image scanning into CI/CD and continue rescanning deployed images as new vulnerabilities are disclosed. - **Implement admission controls:** Reject workloads that violate security policies, use unapproved images, or request excessive privileges before deployment. - **Monitor Kubernetes runtime activity:** Detect suspicious processes, network connections, privilege changes, and API activity across containers and nodes. - **Secure the Kubernetes software supply chain:** Protect repositories, build systems, registries, signatures, SBOMs, and deployment pipelines from tampering. - **Apply least privilege across the entire environment:** Minimize permissions across Kubernetes, cloud identities, nodes, registries, CI/CD systems, and external services. This is part of a series of articles about container security. ## Why is Kubernetes security important? Kubernetes often runs critical applications across distributed clusters, making it a valuable target for attackers. A security issue in one component can affect workloads, data, or other parts of the cluster. Kubernetes security controls reduce these risks without slowing down how teams ship applications: - **Protect sensitive data:** Kubernetes workloads may process credentials, customer data, API keys, and other sensitive information. Security controls help prevent unauthorized access, exposure, and data theft. - **Limit unauthorized access:** Role-based access control (RBAC), authentication, and authorization restrict what users and service accounts can do within a cluster. Applying least privilege reduces the impact of compromised accounts. - **Reduce workload risks:** Vulnerable container images, excessive privileges, and insecure configurations can expose workloads to attack. Security policies help identify and prevent these conditions before deployment. - **Prevent lateral movement:** Network policies and workload isolation restrict communication between pods and services. These controls make it harder for attackers to move through a cluster after compromising one workload. - **Protect cluster infrastructure:** Kubernetes control plane components and worker nodes require protection because access to them can provide control over workloads and cluster resources. - **Support compliance requirements:** Logging, access controls, policy enforcement, and configuration management help organizations meet security and regulatory requirements while providing evidence for audits. - **Detect threats quickly:** Runtime monitoring and audit logs can reveal suspicious API requests, unexpected process activity, privilege escalation, and other indicators of compromise. ## The Kubernetes security model Kubernetes uses a **shared security model** in which protection depends on controls at several layers. The cloud or infrastructure provider typically secures the underlying compute, storage, and networking. **Cluster administrators** are responsible for configuring: - Kubernetes components - Access controls - Network policies - Node security **Application teams** must secure: - Container images - Workload configurations - Secrets - Application code The Kubernetes API server is a central security boundary. Requests to the API pass through authentication, authorization, and admission control before Kubernetes accepts them. Authentication verifies the requester, while authorization determines which operations are allowed. Admission controllers can then validate or modify requests based on security policies before objects are created or changed. Workload security relies on isolation and least privilege: - **RBAC** limits which users and service accounts can access each Kubernetes resource. - **Security contexts** control capabilities such as user IDs, filesystem permissions, and Linux privileges. - **Pod Security Standards** can restrict risky configurations, including privileged containers and unnecessary access to the host. - **Network policies** can further limit which pods are permitted to communicate. Kubernetes security also extends beyond preventive controls. Audit logging records activity against the Kubernetes API, while runtime monitoring can identify suspicious processes, network connections, and changes inside containers. Image scanning and configuration checks help detect vulnerabilities earlier in the deployment lifecycle. Together, these controls provide defense in depth rather than relying on a single security mechanism. ## Common Kubernetes security risks ### Insecure workload configurations Insecure workload configurations are a frequent source of vulnerabilities in Kubernetes environments. Examples include running containers with root privileges, failing to set resource limits, or allowing privilege escalation. Such misconfigurations can provide attackers with broad access if a container is compromised, enabling them to affect other workloads or gain control over the underlying host. Developers and operators may unintentionally introduce insecure configurations due to lack of awareness or pressure to deploy quickly. **How to address:** Automated configuration validation and policy enforcement catch these issues before a workload reaches the cluster, when they are cheapest to fix. Regular audits against the Pod Security Standards then find the configurations that slipped through or drifted after deployment. ### Excessive Kubernetes permissions Granting excessive permissions to users, service accounts, or workloads is a common risk in Kubernetes clusters. Over-permissioned roles can allow attackers to perform unauthorized actions, such as modifying cluster resources, accessing sensitive data, or escalating privileges across namespaces. This risk is heightened when default or broad permissions are assigned without careful consideration. **How to address:** To mitigate this threat, organizations should implement the principle of least privilege, granting only the minimum permissions necessary for each user or workload. Regularly reviewing RBAC policies and monitoring permission usage can help identify and remediate excessive privileges before they are exploited by malicious actors. ### Exposed Kubernetes API servers The Kubernetes API server is the primary control point for managing cluster resources. If exposed to the public internet or poorly protected, it becomes a high-value target for attackers. Unauthorized access to the API server can lead to full cluster compromise, enabling attackers to deploy malicious workloads or exfiltrate sensitive information. **How to address:** Securing the API server involves restricting access to trusted networks, enabling strong authentication and encryption, and regularly auditing access logs. Disabling anonymous access and enforcing network policies further reduce the risk of unauthorized API interactions. Continuous monitoring of API activity matters because a stolen credential looks legitimate at the authentication step, and unusual requests are often the first sign of it. ### Container image vulnerabilities Container images often contain [known vulnerabilities](https://mazehq.com/learn/common-vulnerabilities-and-exposures-cve-basics-and-best-practices) in system libraries, application dependencies, or base operating systems. If these images are deployed without proper scanning and patching, attackers can exploit vulnerabilities to gain access or escalate privileges within the cluster. The use of outdated or unverified images from public registries increases this risk. **How to address:** To address this, organizations should implement automated image scanning in their CI/CD pipelines and enforce policies that block vulnerable images from being deployed. Using minimal base images, keeping dependencies up to date, and sourcing images from trusted registries further reduce the attack surface associated with container images. Because scanners flag every CVE in every package whether or not it can be exploited in the workload, the best teams decide what to fix first based on how each image actually runs in the cluster, rather than on severity scores alone. ### Misconfigured Kubernetes components Misconfigurations in Kubernetes components such as etcd, kubelet, or the control plane can introduce significant security risks. Examples include exposing etcd without encryption, enabling insecure ports, or running components with unnecessary privileges. Attackers can exploit these weaknesses to access sensitive data or disrupt cluster operations. **How to address:** Review and harden the configuration of every cluster component, including disabling unused features, enforcing encryption, and following vendor security recommendations. Automated configuration management and compliance scanning tools keep those settings consistent across clusters, so a hardened setting doesn’t quietly revert during an upgrade or a manual change. ### Kubernetes secrets exposure Kubernetes secrets are used to store sensitive information such as passwords, API keys, and certificates. If not properly protected, secrets can be accessed by unauthorized users or exposed through misconfigured workloads. Storing secrets in plain text or failing to restrict access increases the likelihood of a data breach. **How to address:** To protect secrets, organizations should use encryption at rest, restrict access via RBAC, and avoid exposing secrets as environment variables or in logs. Integrating external secret management solutions and regularly rotating secrets further strengthens the security of sensitive information within the cluster. ## Kubernetes security best practices Here are some of the ways that organizations can improve their security when working with Kubernetes. ### 1. Keep Kubernetes and cluster components updated It’s important to regularly update Kubernetes, node operating systems, container runtimes, and supporting components to address known vulnerabilities. Managed Kubernetes services can simplify control plane upgrades, but organizations remain responsible for worker nodes, add-ons, and workload dependencies. Maintaining an inventory of component versions helps identify systems that require remediation. **Key actions:** - Track Kubernetes security advisories and vendor patches. - Avoid running versions that have reached end of support. - Test upgrades in a non-production environment before applying them to production clusters. - Establish a repeatable patching process rather than relying on occasional manual updates. ### 2. Implement Kubernetes RBAC Role-based access control (RBAC) helps restrict access to Kubernetes resources based on job or workload requirements. Namespace-scoped Roles should be preferred where possible and ClusterRoles should be reserved for permissions that genuinely require cluster-wide access. **Key actions:** - Avoid broad permissions such as wildcard verbs or resources unless they are necessary. - Review RoleBindings and ClusterRoleBindings regularly to identify unused or excessive privileges. - Ensure that service accounts receive only the permissions their workloads require. - Avoid assigning cluster-admin to users, groups, or service accounts for routine operations. ### 3. Enforce pod security standards Kubernetes Pod Security Standards help prevent workloads from using unsafe security settings. The Baseline profile blocks known privilege escalations such as privileged containers, host namespaces, and dangerous Linux capabilities. The Restricted profile goes further by requiring containers to run as non-root, drop all capabilities, and block privilege escalation, which limits the impact of a container compromise. **Key actions:** - Use Pod Security Admission to enforce these standards at the namespace level using enforce, audit, or warn modes. - Begin with audit or warn mode to identify incompatible workloads before enabling enforcement. - Ensure that workload security contexts also specify settings such as non-root execution and restricted privilege escalation. ### 4. Use Kubernetes network policies Network policies control which network connections pods can establish or accept. Without effective network restrictions, compromised workloads may be able to communicate with unrelated services and move laterally through the cluster. **Key actions:** - Define policies around expected application communication rather than allowing unrestricted pod-to-pod traffic. - Start with default-deny ingress and egress policies where operationally practical, then explicitly allow required connections. - Ensure the cluster’s container network interface (CNI) plugin supports and enforces network policies. - Test policies carefully so that required services such as DNS, monitoring, and external APIs remain reachable. ### 5. Encrypt Kubernetes secrets Kubernetes stores Secrets in etcd base64-encoded, and unless encryption at rest is configured they are not encrypted, so anyone who gains access to etcd or its backups can read their contents. **Key actions:** - Configure the API server with an appropriate encryption provider and protect the encryption keys separately. - Restrict secret access through RBAC and avoid granting workloads permission to list secrets when they only need specific values. - Consider an external secrets manager for centralized storage, access auditing, and rotation. - Prevent secrets from appearing in container images, configuration files, source repositories, and application logs. ### 6. Scan container images for vulnerabilities Container images should be scanned for known vulnerabilities before they reach production. Integrate scanning into CI/CD pipelines so vulnerable operating system packages and application dependencies can be detected before deployment. Scanning should continue after deployment because new vulnerabilities can be discovered in existing images. **Key actions:** - Define severity and remediation policies that determine when a build should be blocked. - Maintain an inventory of deployed images and rescan them when vulnerability databases change. - Prioritize fixes by whether a vulnerability can be exploited in the workload running the image, since many flagged packages are never loaded or depend on features that are turned off. - Rebuild affected images with patched dependencies instead of modifying running containers manually. ***Related content: Read our guide to [vulnerability management](https://mazehq.com/learn/vulnerability-management-process-metrics-and-technologies).*** ### 7. Implement admission controls Admission controls evaluate Kubernetes API requests before resources are created or modified. Kubernetes includes built-in admission controllers, while policy engines can enforce organization-specific rules. **Key actions:** - Use admission controls to reject workloads that violate security requirements, such as containers running with excessive privileges, images from unapproved registries, or resources missing required security settings. - Apply policies consistently across clusters and manage them as code so changes can be reviewed and tested. - Use audit or warning modes when introducing new policies to identify potential application conflicts before enforcement. ### 8. Monitor Kubernetes runtime activity Runtime monitoring helps detect threats that configuration checks and image scanning cannot identify before deployment. Organizations must monitor containers and nodes for unexpected processes, privilege changes, suspicious network connections, filesystem modifications, and attempts to access sensitive host resources. **Key actions:** - Combine runtime telemetry with Kubernetes audit logs to provide context about API activity and workload changes. - Send relevant events to a centralized monitoring or security platform and define alerts for high-risk behavior. - Retain sufficient logs to support incident investigation and determine which resources were affected. ### 9. Secure the Kubernetes software supply chain Protecting the path from source code to deployed container involves securing repositories, CI/CD systems, build environments, registries, and deployment processes. Admission policies can prevent unsigned, untrusted, or otherwise noncompliant artifacts from entering clusters. **Key actions:** - Use image digests to deploy immutable artifacts and verify image signatures or attestations before deployment where possible. - Generate software bills of materials (SBOMs) to track included components and dependencies. - Restrict who can modify pipelines or publish images, and protect build credentials from workloads and untrusted code. ***Related content: Read our article about [software composition analysis](https://mazehq.com/learn/software-composition-analysis-how-it-works-6-best-practices).*** ### 10. Apply least privilege across the entire environment Least privilege should apply beyond Kubernetes RBAC. Containers should run without root access when possible, use only required Linux capabilities, and avoid privileged mode, host networking, host process namespaces, and unnecessary host filesystem mounts. Nodes and cloud identities should also receive only the permissions required for their functions. **Key actions:** - Review permissions across Kubernetes, cloud platforms, registries, CI/CD systems, and external services because attackers may cross these boundaries after gaining access. - Separate administrative duties and use short-lived credentials where supported. - Perform periodic access reviews to remove obsolete permissions and reduce the impact of compromised identities. ***Related content: Read our guide to [application security best practices](https://mazehq.com/learn/top-application-security-best-practices-for-leading-appsec).*** ## Securing Kubernetes workloads with Maze While working with security teams, Maze’s founders kept seeing scanners flag thousands of container vulnerabilities that nobody had the context to sort, so teams worked through severity scores that said nothing about how their own clusters were configured or what was actually running. They built Maze so that every vulnerability gets the investigation those teams never had time to run. Given unlimited time, a security engineer looking at a vulnerability in a container would check whether the vulnerable package is ever loaded, whether the feature it depends on is turned on, how the pod is exposed, which namespace it runs in, and what its service account and cloud role can reach. Maze’s AI was built to think the same way. It works out what context each finding needs, gathers it from your code, build, and cloud, and decides whether the vulnerability can be exploited in your environment and how severe it really is, with the evidence behind every verdict. Maze Cloud sees inside your clusters with a read-only role in your cloud account and nothing to install in them, and it investigates the vulnerabilities your existing scanners find in the workloads running there. Maze Code brings the same investigation to your code, using AI to find the vulnerabilities in your code and dependencies. **Key capabilities of Maze Cloud:** - **Investigate every vulnerability in your backlog:** Maze investigates every finding your scanners report, across your clusters and cloud, instead of a sample or only the criticals, so the thousands of vulnerabilities sitting in your backlog each get a verdict with evidence rather than waiting for someone to have time. - **Visibility inside your clusters:** Maps which containers are live across EKS, ECS, and AKS, which images they run, and how each one is exposed, along with the images in registries such as Docker Hub and Azure Container Registry. Findings from your existing scanners are deduplicated, and findings on containers that have stopped running drop down the queue. - **Context-driven investigation:** Investigates every vulnerability, from known CVEs to zero-days, using cluster context such as namespace, security context, network exposure, and the cloud role each workload can use, instead of relying on CVSS or EPSS scores alone. - **Exploitability-based prioritization:** Vulnerabilities that aren’t exploitable are closed with the full reasoning behind the decision. On average, Maze finds that over 70% of vulnerabilities are not exploitable. The ones that can be exploited are ranked on likelihood and impact, so a critical CVE in a staging pod that never sees real traffic doesn’t outrank a medium one in your payment service. - **Base image and layer tracing:** Traces each CVE to the image layer it came from and proposes options such as upgrading the base image or rebuilding to pull in a patch, with the trade-offs of each. - **Fixes and mitigations:** Traces each exploitable vulnerability to its root cause, whether a base image, a build step, or a dependency, bundles CVEs that share a fix into one change, and routes it to the developer who owns it, with a mitigation when no patch exists. - **Zero-day sweeps:** When a new vulnerability is disclosed, Maze picks it up in near real time and checks every affected workload with the same investigation, so teams know whether they’re affected before scanners have caught up. ![Maze product screenshot](https://mazehq.com/wp-content/uploads/2026/06/Investigation-view-single-container-Rnd@2x.png)Source: [Maze](https://mazehq.com/)[Learn more about how Maze investigates and fixes cloud and container vulnerabilities.](https://mazehq.com/platform/cloud)