Summary
Kyverno's apiCall service mode reads the admission controller's ServiceAccount token from /var/run/secrets/kubernetes.io/serviceaccount/token and injects it into every outbound HTTP request as an Authorization: Bearer header when no explicit Authorization header is defined in the policy. This behavior is insecure-by-default and undocumented, meaning any policy using apiCall.service.url silently leaks the Kyverno ServiceAccount token to the target endpoint without the policy author opting in.
Impact
The implicit token forwarding exposes the Kyverno admission controller's ServiceAccount token to any endpoint referenced in a policy's apiCall.service.url. According to the advisory, this token grants full control over Kyverno policies, the ability to create and delete admission webhooks, read access to cluster-wide resources, and a path to privilege escalation and persistence. Any policy author who references an attacker-controlled or untrusted external endpoint — even inadvertently — leaks these high-privilege credentials. Because the behavior is undocumented, affected clusters may be exfiltrating tokens without administrator awareness.
Detection
Review all ClusterPolicy and Policy resources in the cluster for apiCall.service.url fields pointing to external or non-trusted endpoints. Examine Kyverno admission controller pod logs for outbound HTTP requests to unexpected destinations. Audit Kubernetes API server audit logs for unusual activity originating from the Kyverno ServiceAccount, which may indicate that a leaked token has been used for follow-on access.
Mitigation
Upgrade Kyverno to version 1.16.4 or later, which addresses the implicit token forwarding behavior. Until the upgrade is complete, audit all policies using apiCall.service.url and restrict them to trusted internal endpoints only. Ensure the Kyverno ServiceAccount's RBAC permissions follow the principle of least privilege to reduce the blast radius if a token is exfiltrated.