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-83620 — Identity spoofing in Cilium mutual authentication via certificate substitution

HIGH7.6CVE-2026-83620GHSA-33qq-jq9c-6gcc

CVSS vector: CVSS:3.1/AV:A/AC:L/PR:L/UI:N/S:C/C:H/I:L/A:N
Affected projects: cilium
Disclosed: August 12, 2026
Last updated: September 1, 2026

Affected versions

Project	Vulnerable range
Cilium	`>= v1.19.0, < v1.19.6`
Cilium	`>= v1.18.0, < v1.18.12`
Cilium	`>= v1.17.0, < v1.17.18`
Cilium	`>= v1.14.0, <= v1.16.19`

Patched versions

Project	Fixed in
Cilium	`v1.19.6`
Cilium	`v1.18.12`
Cilium	`v1.17.18`

References

GHSA-33qq-jq9c-6gcc

Summary

In Cilium clusters with mutual authentication enabled, an attacker holding any valid client certificate can completely bypass mutual authentication and impersonate any other identity in the cluster. The attack is executed by obtaining the public certificate of the target identity and appending it to the attacker's certificate chain during the TLS handshake. Cilium mutual authentication is a beta feature that has been marked for deprecation. This issue is patched by a commit included in Cilium v1.17.18, v1.18.12, and v1.19.6.

Impact

An attacker with a valid client certificate and network adjacency to the targeted workload can impersonate any cluster identity, including high-privilege service identities, by appending the target's public certificate to their TLS chain. This completely undermines the mutual authentication guarantee, allowing unauthorized access to services that rely on Cilium identity-based L4 or L7 policies enforced through mutual auth. The affected version range spans Cilium v1.14.0 through v1.19.5. Clusters that do not use Cilium's mutual authentication feature are not affected.

Detection

There is no published Cilium-specific detection rule for this vulnerability. Administrators using mutual authentication should examine mTLS audit logs or Envoy access logs for connections where the certificate subject does not match the expected workload identity. Reviewing Cilium audit logs for unexpected identity resolutions on authenticated paths may surface anomalous peer identities. Consult the references for the upstream advisory and Cilium Slack for any community-developed detection guidance.

Mitigation

Upgrade Cilium to a patched version:

v1.17.x: upgrade to v1.17.18 or later
v1.18.x: upgrade to v1.18.12 or later
v1.19.x: upgrade to v1.19.6 or later

Clusters running v1.14.x, v1.15.x, or v1.16.x are affected and should upgrade to v1.17.18 or a later supported release, as those branches do not receive backported patches. There is no known workaround for this issue. Disabling Cilium's mutual authentication feature eliminates the attack surface entirely; given that mutual authentication is a beta feature marked for deprecation, disabling it is a viable interim measure for clusters that do not depend on it.

References

GHSA-33qq-jq9c-6gcc — GitHub Security Advisory

Affected versions

Patched versions

References

Summary​

Impact​

Detection​

Mitigation​

Related Security Guidance​

References​

Summary

Impact

Detection

Mitigation

Related Security Guidance

References