On March 6, 2024, the Kubernetes security team disclosed CVE-2024-3177, a vulnerability in Kubernetes that allowed pods to bypass the "mountable secrets" restriction enforced by service account admission controls. While rated medium severity (CVSS 5.0), this flaw is particularly significant for organizations running multi-tenant Kubernetes clusters where secret isolation between workloads is a security requirement.
Understanding the Vulnerability
Kubernetes service accounts can be annotated with kubernetes.io/enforce-mountable-secrets: "true" to restrict which secrets a pod using that service account can mount. This is a defense-in-depth measure that prevents workloads from accessing secrets they do not need, limiting the blast radius if a pod is compromised.
CVE-2024-3177 allowed this restriction to be bypassed. Specifically, the vulnerability existed in how Kubernetes handled secrets referenced through certain volume types. While the admission controller correctly enforced restrictions for secrets mounted via secret volume types, it did not properly enforce the same restrictions for secrets referenced through other mechanisms, including:
- Environment variables using
secretKeyRef - Projected volumes containing secret sources
imagePullSecretsin the pod specification
An attacker with the ability to create or modify pod specifications (a common permission in multi-tenant clusters) could reference secrets that should have been restricted by the mountable secrets policy. This effectively rendered the policy incomplete, giving a false sense of security isolation.
Who Is Affected
This vulnerability affects all Kubernetes versions prior to the patched releases (1.27.13, 1.28.9, 1.29.4, and 1.30.0-rc.1). However, it only impacts clusters that actively use the mountable secrets annotation as a security control.
In practice, this means the vulnerability is most relevant for:
Multi-tenant clusters where different teams or applications run in the same cluster and secret isolation is enforced through service account restrictions.
Managed Kubernetes platforms that use service account annotations to limit what their customers' workloads can access.
Security-hardened deployments where administrators have layered multiple admission controls to enforce least-privilege access to secrets.
If your cluster does not use the kubernetes.io/enforce-mountable-secrets annotation, this CVE does not directly affect you. But its existence is a reminder that Kubernetes admission controls can have subtle gaps that are not obvious from the documentation.
The Broader Context of Kubernetes Secrets Security
CVE-2024-3177 highlights a persistent challenge in Kubernetes security: the gap between what operators think their security controls enforce and what they actually enforce.
Kubernetes secrets have been a contentious topic in the security community for years. By default, Kubernetes secrets are stored in etcd as base64-encoded data (not encrypted). They are accessible to anyone with the appropriate RBAC permissions. They are mounted as files or injected as environment variables, both of which can be accessed by any process in the pod.
Organizations that take Kubernetes security seriously typically layer multiple controls:
- RBAC policies limiting who can read, list, and watch secrets
- Service account mountable secrets annotations to restrict pod-level access
- External secret management systems (HashiCorp Vault, AWS Secrets Manager, etc.) that inject secrets at runtime
- Pod Security Admission or OPA/Gatekeeper policies that restrict pod configurations
- etcd encryption at rest to protect secrets in the data store
CVE-2024-3177 punched a hole in the second layer. It did not make all secrets accessible to everyone, but it meant that organizations relying on the mountable secrets annotation as a key isolation boundary had a weaker posture than they believed.
Remediation
The fix was included in Kubernetes versions 1.27.13, 1.28.9, 1.29.4, and 1.30.0-rc.1. The patch extends the admission controller to properly enforce mountable secrets restrictions across all secret reference types, not just secret volumes.
Organizations running affected versions should upgrade their Kubernetes control plane to the patched versions. In the interim, additional admission control policies (via OPA/Gatekeeper or Kyverno) can be used to enforce secret access restrictions at the policy engine level, providing a compensating control while the upgrade is planned.
It is also worth conducting an audit of your cluster to determine whether any pods are currently referencing secrets through the bypass vectors. If you find pods that are accessing secrets they should not have access to, this may indicate either a legitimate configuration gap or potentially malicious activity that was exploiting the vulnerability.
Lessons for Kubernetes Operators
This CVE reinforces several principles that Kubernetes operators should already be following:
Do not rely on a single control for secret isolation. The mountable secrets annotation is a useful layer, but it should be combined with RBAC restrictions, external secret management, and policy engine rules.
Test your security controls with adversarial thinking. The bypass vectors for CVE-2024-3177 were not exotic. Anyone who thought carefully about all the ways a pod can reference a secret could have identified the gap. Periodic security reviews of your admission control policies should include testing for these kinds of bypass scenarios.
Keep your control plane updated. Kubernetes releases security patches regularly, and control plane upgrades, while operationally complex, are essential for maintaining your security posture.
Monitor for anomalous secret access patterns. Kubernetes audit logs can record when secrets are accessed. Monitoring for pods accessing secrets outside their expected scope can provide early warning of exploitation.
How Safeguard.sh Helps
Safeguard.sh provides continuous vulnerability monitoring for your container infrastructure, including Kubernetes components. When CVEs like CVE-2024-3177 are published, Safeguard.sh maps them against your deployed Kubernetes versions and alerts you to exposure. Our SBOM-driven approach extends beyond application dependencies to include infrastructure components, ensuring that Kubernetes control plane vulnerabilities are tracked alongside application-level issues. Policy gates can enforce minimum Kubernetes version requirements, preventing clusters running known-vulnerable versions from hosting production workloads.