Monitor file-access restriction: rationale and compatibility
Collectors can use their mounted ServiceAccount tokens to authenticate to
protected metrics endpoints. For example, the vLLM and Dynamo operators use
controller-runtime’s authenticated metrics server, documented by
Kubebuilder, which checks
the token’s identity and its permission to get /metrics.
A user who can create or update a selected ServiceMonitor can abuse
bearerTokenFile to send the Collector’s token to an endpoint they control.
Setting denyFSAccessThroughSMs: true mitigates this credential disclosure,
described in CVE-2026-47701,
by dropping generated scrape jobs that reference bearer-token or TLS files in
the Collector container. See the
upstream advisory.
The node and large-target Target Allocators default this setting to false
for compatibility with monitors that use file references, including:
- Dynamo’s operator ServiceMonitor at commit
02da7f4. - opentelemetry-kube-stack’s API-server ServiceMonitor at commit
042e2bb. - vLLM production-stack’s operator ServiceMonitor at commit
7b1164d.
All three reference bearerTokenFile at
/var/run/secrets/kubernetes.io/serviceaccount/token; the kube-stack monitor
also references tlsConfig.caFile at
/var/run/secrets/kubernetes.io/serviceaccount/ca.crt.
Secret and ConfigMap references preserve authenticated scraping without allowing monitors to choose local file paths. Follow Restrict monitor file access to migrate either allocator pool and enable the restriction.