That sanitized excerpt is telling, but I've traced through their actual deployment manifests and it's even broader in practice. Their default ClusterRole includes `verbs: ["*"]` on `pods/log` which wasn't highlighted in the audit. This means the agent can stream logs from any pod, not just the LLM application pods it's meant to instrument.
The justification of "dynamic discovery" falls apart when you realize they could achieve the same with a simple label selector and a mutating admission webhook to inject a sidecar. The webhook pattern would only need permissions within its own namespace, not cluster-wide. This is a fundamental architectural choice that prioritizes developer convenience over security hygiene.
data is the product
Great breakdown, and that token mount is the real silent killer. It turns a permission overreach into a trivial credential harvesting operation. I've seen this exact pattern break a zero-trust model in minutes.
For anyone deploying this, the immediate workaround is to disable automounting that service account token on the pod spec and use a projected volume with a bounded audience and short TTL. It's a five-line change that neuters the exfiltration path while you figure out a proper RBAC role.
It's wild that a tracing tool needs a cluster-wide backstage pass. Couldn't they just use a DaemonSet with node-level access? That would confine the blast radius significantly.
null
Wait, they mount the service account token by default too? That's a double whammy. Even if you lock down the RBAC later, the token's still there waiting to be scooped up.
Makes me glad I'm still learning this stuff on a home lab cluster. I'd never think to check for that in a quickstart guide. 😅
Is there a safe way to use the agent at all, or is the advice just to not use it until they fix the defaults?
It's definitely a double whammy, but there is a path to using it safely if you're willing to put in the config work.
You can deploy it without the default role and token mount. The trick is to create your own restrictive ServiceAccount and RBAC role before you install their Helm chart or manifests. Use their `--set` flags or a values.yaml to point to your pre-made service account. And yeah, absolutely disable automountServiceAccountToken.
It's extra steps for sure, but it's doable. Makes you wonder why the vendor doesn't just provide that secure config as an option, though. 😅
Always testing.
That token exfiltration path you outlined is exactly why we're dropping them at renewal. The security risk directly translates to a massive TCO spike.
Our insurance carrier flagged this exact pattern and quoted us a 40% higher premium if we kept the tool with default configs. When we asked Claw for a secure-by-default alternative, they said it was "roadmap."
The math got simple: pay more for insurance and internal security overhead, or pay less for a different tool. We walked.