Executive Summary

This vulnerability in Fission, a Kubernetes-native serverless framework, arises because user function containers inherited the fission-fetcher ServiceAccount token. This token granted broad namespace-wide read access to Kubernetes secrets and configmaps.

Since the runtime pods used the fission-fetcher ServiceAccount, which had permissions to get secrets and configmaps, the automounted token inside the user function container allowed user-supplied function code to read any secret or configmap in the function's namespace. This access exceeded the intended restrictions defined by the Function.spec.secrets allowlist.

The root cause is that Kubernetes does not support per-container service-account scoping within a single pod, so the user container inherited the pod's service-account token, which was originally needed by the fetcher sidecar for legitimate operations.

The issue was fixed in Fission version 1.23.0 by disabling the automounting of the service-account token for the user function container while keeping it enabled for the fetcher sidecar container.

Useful 0 Not Useful 0

Compliance Impact

This vulnerability allows user-supplied function code to read any secret or configmap in the function's namespace, potentially exposing sensitive data such as TLS keys, credentials, or database connection details.

Such unauthorized access to sensitive information can lead to violations of data protection principles and requirements found in common standards and regulations like GDPR and HIPAA, which mandate strict controls over access to personal and sensitive data.

By exposing secrets beyond the intended allowlist, the vulnerability undermines confidentiality and access control measures, increasing the risk of non-compliance with these regulations.

Useful 0 Not Useful 0

Impact Analysis

An attacker who can deploy or update a function in any namespace where Fission runtime pods run can exploit this vulnerability to read all secrets and configmaps in that namespace.

This could lead to exposure of sensitive data such as TLS keys, credentials, database connection details, and other confidential information stored as Kubernetes secrets or configmaps.

Because the user function code inherits broad Kubernetes API privileges, it bypasses the intended security restrictions, potentially leading to unauthorized data access and compromise of the environment.

Useful 0 Not Useful 0

Detection Guidance

This vulnerability can be detected by checking if the Fission runtime pods are automounting the fission-fetcher ServiceAccount token inside user function containers. Specifically, you can verify if the token is accessible at the path /var/run/secrets/kubernetes.io/serviceaccount/token within the user function container.

You can use kubectl commands to inspect the pods and their service account token mounts. For example:

• kubectl get pods -n <namespace> -o jsonpath='{.items[*].spec.containers[*].volumeMounts}' | grep serviceaccount
• kubectl exec -n <namespace> <pod-name> -c <user-function-container> -- ls /var/run/secrets/kubernetes.io/serviceaccount/
• kubectl describe pod -n <namespace> <pod-name> | grep ServiceAccountName

If the user function container has the service account token automounted, it indicates the vulnerability is present.

Useful 0 Not Useful 0

Mitigation Strategies

Immediate mitigation steps before upgrading to Fission version 1.23.0 include:

• Restrict who can create or update Function and Package Custom Resource Definitions (CRDs) to limit the ability to deploy or modify functions.
• Reduce the scope of the fission-fetcher ClusterRole to limit its permissions on secrets and configmaps.
• Add Kubernetes NetworkPolicy egress rules to block function pods from accessing the Kubernetes API server, preventing unauthorized API calls.

The definitive fix is to upgrade to Fission version 1.23.0 or later, where the automounting of the service account token for user function containers is disabled, while still allowing the fetcher sidecar to access it.

Useful 0 Not Useful 0