What is Kubernetes security?

Kubernetes security encompasses the practices, tools, and configurations used to protect Kubernetes clusters, workloads, and data. It includes authentication, authorization (RBAC), network policies, pod security standards, secrets management, and runtime security.

What is the CKS certification?

The Certified Kubernetes Security Specialist (CKS) is a CNCF certification that validates expertise in securing Kubernetes clusters. It covers cluster setup and hardening, system hardening, minimizing microservice vulnerabilities, and supply chain security.

What are Kubernetes network policies?

Network policies are Kubernetes resources that control pod-to-pod and pod-to-external traffic. They act as a firewall for your cluster, allowing you to specify which pods can communicate with each other based on labels, namespaces, and ports.

What are Pod Security Standards?

Pod Security Standards (PSS) are predefined security profiles that define different levels of pod security restrictions: Privileged (unrestricted), Baseline (minimally restrictive to prevent known privilege escalations), and Restricted (heavily restricted following security best practices).

What is RBAC in Kubernetes?

Role-Based Access Control (RBAC) is a Kubernetes authorization mechanism that regulates access to resources based on user roles. It uses Role, ClusterRole, RoleBinding, and ClusterRoleBinding resources to define and assign permissions to users and service accounts.

How do I secure etcd in Kubernetes?

Secure etcd by enabling encryption at rest for secrets, using TLS for client-server communication, restricting access to etcd endpoints via firewall rules, enabling authentication, and running regular backups. etcd stores all cluster data including secrets.

What is a container escape attack?

A container escape attack occurs when a process breaks out of container isolation to access the host system or other containers. Common vectors include privileged containers, hostPath mounts, and kernel exploits. Mitigate with Pod Security Standards and seccomp profiles.

What tools are used for Kubernetes security scanning?

Popular Kubernetes security tools include Trivy (vulnerability scanning), Falco (runtime security), kube-bench (CIS benchmarks), OPA Gatekeeper and Kyverno (policy enforcement), Kubescape (security posture), and Cosign (image signing).

CVE-2026-40868 — Kyverno apiCall implicit bearer token injection

HIGH8.1CVE-2026-40868GHSA-q93q-v844-jrqp

CVSS vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N
Affected projects: kyverno
Disclosed: April 13, 2026
Last updated: October 27, 2026

Affected versions

Project	Vulnerable range
github.com/kyverno/kyverno	`< 1.17.0`

Patched versions

Project	Fixed in
github.com/kyverno/kyverno	`1.17.0`

References

Summary

Kyverno's apiCall service-call helper implicitly injects Authorization: Bearer <token> using the Kyverno controller's ServiceAccount token whenever a policy does not explicitly set an Authorization header. Because context.apiCall.service.url is fully policy-controlled, this design sends the Kyverno SA token to any endpoint the policy author specifies — a classic confused-deputy problem. Namespaced policies are blocked from service-call usage by the urlPath gate in pkg/engine/apicall/apiCall.go, so this issue is scoped to ClusterPolicy and global-context entries.

Impact

An attacker who can create or update a ClusterPolicy (or a GlobalContextEntry) that uses context.apiCall.service.url can direct the request URL to an attacker-controlled host and observe the implicitly injected Bearer token. A realistic path is a compromised GitOps policy repository: if the policy store is tampered with, the resulting ClusterPolicy becomes untrusted input that Kyverno executes with its own high-privilege SA. With the default Helm RBAC binding, the leaked token grants read and patch rights over admission webhook configurations, which is sufficient to subvert the entire admission layer.

Detection

Audit ClusterPolicy and GlobalContextEntry resources for apiCall.service.url values pointing outside the cluster — any URL lacking an .svc suffix or resolving to a public IP or external DNS name should be treated as a potential exfiltration sink. Pair this with audit-log review for patch operations against MutatingWebhookConfiguration and ValidatingWebhookConfiguration performed by the Kyverno admission controller's SA outside expected reconciliation windows.

Mitigation

Upgrade Kyverno to v1.17.0 or later. Until patched:

Restrict who can create or update ClusterPolicy and GlobalContextEntry resources via tight RBAC.
Audit all existing policies for apiCall.service.url values pointing outside the cluster; remove or relocate any external references.
After upgrading, rotate the Kyverno SA token if there is any reason to suspect a malicious policy was applied during the affected window.

Service Account Token Projection Abuse — how SA token exfiltration is exploited
Securing Kubernetes Service Accounts — least-privilege SA configuration
Kyverno — hardening Kyverno deployments

Affected versions

Patched versions

References

Summary​

Impact​

Detection​

Mitigation​

Related Security Guidance​

References​

Summary

Impact

Detection

Mitigation

Related Security Guidance

References