A critical security vulnerability, identified as CVE-2024-3177, has been discovered in Kubernetes that allows unauthorized users to launch containers that bypass the mountable secrets policy enforced by the ServiceAccount admission plugin. This issue arises when using containers, init containers, and ephemeral containers that have the envFrom field populated. The policy is designed to ensure that pods running with a service account can only reference secrets specified in the service account's secrets field.

The ServiceAccount admission plugin is used

2. The kubernetes.io/enforce-mountable-secrets annotation is present

Containers, init containers, and ephemeral containers have the envFrom field populated

In this blog post, we will discuss the details of this vulnerability, how to exploit it, and how to mitigate the risk.

Vulnerability Details

The vulnerability stems from the fact that the ServiceAccount admission plugin's enforcement of the mountable secrets policy can be bypassed by using the envFrom field. When this field is populated, containers are allowed to reference secrets that are not listed in the service account's secrets field.

The following code snippet demonstrates how this can be exploited

apiVersion: v1
kind: Pod
metadata:
  annotations:
    kubernetes.io/enforce-mountable-secrets: "true"
  name: example-pod
spec:
  containers:
  - name: example-container
    image: example/image
    envFrom:
    - secretRef:
        name: bypassed-secret

In the example above, a container is created that references a secret (bypassed-secret) that is not listed in the service account's secrets field. The ServiceAccount admission plugin should normally prevent this from happening, but it does not check for secrets referenced in the envFrom field, which allows the bypass to occur.

More information on this vulnerability can be found in the following references and resources

1. CVE-2024-3177 Details - NIST National Vulnerability Database
2. Kubernetes Security Issue - GitHub

Exploiting the Vulnerability

To exploit this vulnerability, an attacker would need access to a Kubernetes cluster that meets the conditions mentioned above (i.e., uses the ServiceAccount admission plugin, has the kubernetes.io/enforce-mountable-secrets annotation, and uses containers with the envFrom field populated).

The attacker could then create a container, init container, or ephemeral container with the envFrom field referencing a secret that is not specified in the service account's secrets field. This would allow the attacker to bypass the mountable secrets policy and gain unauthorized access to sensitive information stored in the bypassed secret.

Mitigation and Remediation

To mitigate this vulnerability, cluster administrators should ensure that they are not relying solely on the ServiceAccount admission plugin and the kubernetes.io/enforce-mountable-secrets annotation to enforce mountable secrets policies. Instead, additional security measures should be implemented to prevent unauthorized access to secrets, such as:

Restricting the use of the envFrom field in pod specifications

2. Using Kubernetes RBAC to limit the permissions of users and service accounts in the cluster
3. Enforcing network policies to isolate pods and namespaces from each other
4. Implementing admission webhooks or other custom policies to prevent the creation of pods that do not adhere to the desired security standards

It is also strongly recommended that Kubernetes users stay informed about security updates and patches released for the platform and apply them as soon as possible to minimize the risk of vulnerability exploitation.

Conclusion

CVE-2024-3177 is a critical security vulnerability that affects Kubernetes clusters using a specific set of configurations. By exploiting this vulnerability, unauthorized users can bypass the mountable secrets policy and potentially gain access to sensitive information stored in Kubernetes secrets. It is crucial for cluster administrators to be aware of this issue and take appropriate mitigation measures to protect their infrastructure and data.

Timeline

Published on: 04/22/2024 23:15:51 UTC
Last modified on: 05/01/2024 19:15:27 UTC