External Secrets Operator Privilege Escalation Vulnerability via Service Account Token Injection

A vulnerability in External Secrets Operator prior to version 2.4.1 allows users with permission to create ExternalSecret resources to inject long-lived tokens into Kubernetes Secrets. These tokens can be used to impersonate any service account in the namespace, bypassing the need for direct permissions on TokenRequest or specific Secrets. The issue arises from improper validation of secret templates, particularly those related to service account tokens.

Impact

Exploitation of this vulnerability allows for unauthorized impersonation of service accounts, potentially leading to elevated privileges and access to sensitive resources within the namespace.

Reproduction

To reproduce this vulnerability, create an ExternalSecret resource that includes a template targeting the 'kubernetes.io/service-account-token' secret type. Ensure that the template includes an annotation specifying the service account name. Once the ExternalSecret is applied, the operator will create a Secret populated with a token for the specified service account, which can then be used for impersonation.

Remediation

Users can upgrade to External Secrets Operator version 2.4.1 or later, where this vulnerability has been addressed. For those unable to upgrade, it is recommended to add admission control logic to prevent the use of Templates targeting service account token types, remove Service Account Token generation via kube-controller-manager flags, and restrict User RBAC on production clusters and sensitive namespaces.