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).

GHSA-fx35-mq7g-6g98 — Cosign verification bypass via public key in legacy bundle

HIGH7.4GHSA-fx35-mq7g-6g98

CVSS vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:N/I:H/A:N
Affected projects: cosign
Disclosed: August 6, 2026

Affected versions

Project	Vulnerable range
github.com/sigstore/cosign/v3	`<= 3.1.2`
github.com/sigstore/cosign/v2	`<= 2.6.4`

Patched versions

Project	Fixed in
github.com/sigstore/cosign/v3	`v3.1.3`
github.com/sigstore/cosign/v2	`v2.6.5`

References

GHSA-fx35-mq7g-6g98

Summary

In cosign verify-blob and cosign verify-blob-attestation, keyless verification using --certificate-identity and --certificate-oidc-issuer (or their regular expression equivalents) can be bypassed when a legacy JSON --bundle is supplied. When reading the cert field of a legacy bundle, if the contents failed to parse as an X.509 certificate, Cosign silently fell back to loading the input as a raw public key and populated co.SigVerifier. In downstream verification, whenever co.SigVerifier is set, X.509 certificate chain validation and policy enforcement (CheckCertificatePolicy) are skipped, causing --certificate-identity and --certificate-oidc-issuer flags to be ignored. This does not affect verification with the newer standardized Sigstore protobuf bundle format, which is the default in Cosign v3.

Impact

An attacker can bypass keyless identity and OIDC issuer pinning in cosign verify-blob and cosign verify-blob-attestation by supplying a legacy bundle whose cert field contains an arbitrary bare public key (-----BEGIN PUBLIC KEY-----) instead of a Fulcio X.509 certificate. Verification completes with exit code 0 and reports Verified OK, causing operators or CI/CD pipelines to trust and consume artifacts signed by an unauthorized key. Additionally, if an operator explicitly specifies --key while verifying against a legacy bundle containing a bare public key, the attacker's bundle key silently overrides the --key value. OCI container image verification (cosign verify and cosign verify-attestation) is not affected.

Detection

Inspect CI/CD pipeline invocations of cosign verify-blob or cosign verify-blob-attestation to identify calls that use --bundle with legacy JSON bundles. Audit bundle files to confirm the cert field contains a PEM-encoded X.509 certificate (beginning with -----BEGIN CERTIFICATE-----) rather than a bare public key (beginning with -----BEGIN PUBLIC KEY-----). Any pipeline that relies on --certificate-identity or --certificate-oidc-issuer for verification against a legacy bundle should be treated as potentially bypassed on affected versions.

Mitigation

Upgrade Cosign to a patched version:

Cosign v3.x: upgrade to v3.1.3 or later
Cosign v2.x: upgrade to v2.6.5 or later

As a workaround, migrate from legacy JSON bundles to the modern Sigstore protobuf bundle format (--new-bundle-format). The protobuf bundle verification engine is not affected by this vulnerability. Existing legacy bundles can be upgraded using cosign bundle create.

References

GHSA-fx35-mq7g-6g98 — GitHub Security Advisory

Affected versions

Patched versions

References

Summary​

Impact​

Detection​

Mitigation​

Related Security Guidance​

References​

Summary

Impact

Detection

Mitigation

Related Security Guidance

References