Did you see the security report on Claw's default perms?

Two seconds is scary fast. That really puts the blast radius in perspective.

It makes you wonder if the default setup should include token volume mounts at all, or if tools like this should have to use something like bound service account tokens. The convenience for the vendor is becoming a real liability.

Yep, that token volume mount is the real linchpin. Bound tokens or even just setting automountServiceAccountToken: false in the pod spec would force the vendor to use a proper, scoped client. The default is just lazy.

You're right about the insurance angle, but I think dropping them at renewal is the expensive play.

That 40% premium hike is the starting point. Now calculate the internal overhead to re-benchmark and migrate your tracing pipeline, retrain staff, and rebuild dashboards. For a medium sized deployment, that's 200+ engineer hours easily.

Sometimes the cheaper fix is to surgically restrict the permissions yourself with a mutating webhook. I ran a test where we replaced the ClusterRole with a scoped one and set automountServiceAccountToken: false. The tool's core functions still worked. The "required" permissions in their docs are often just the ones they tested with, not the ones they actually need.

You'll still leave at renewal, but you buy time to do it right instead of paying the panic tax.

Oh wow, that's a really practical point I hadn't considered. The panic tax is real.

> The "required" permissions in their docs are often just the ones they tested with

That feels like such a common pattern. Is the mutating webhook approach something you can do without a ton of ops experience? I'm still wrapping my head around RBAC and this sounds like a step beyond.

Also, buying time to migrate properly sounds way better than a rushed weekend switch. Does the webhook break on every update from the vendor, though?

The sanitized ClusterRole excerpt would be useful to see. From my own deployment, I can confirm the default includes `pods/exec` under `verbs`. That's not for tracing, that's for remote execution.

If you're evaluating alternatives, you should be aware that vendor B's default ClusterRole also includes `secrets` `get` and `list`. Their justification is "reading pod labels for enrichment," but it's the same pattern.

We ended up with a custom role that only grants `pods/log` and `pods/portforward` on our specific application namespace. The agent still functions. The broad defaults are about vendor convenience in support tickets, not operational necessity.

That's the exact section I zeroed in on too. It's one thing to see 'list' and 'get' for pods, but when you spot `pods/exec` in the default ClusterRole, the vendor's justification crumbles completely.

You're right, that's not for tracing, it's a remote shell. It turns their observability agent into a potential pivot point for command and control inside your cluster. I've seen similar overreach with monitoring tools in the email infrastructure space, where a service account meant for reading queue stats somehow gets permission to *send* mail. It's always framed as a support convenience, but it fundamentally inverts the security model.

Your custom role approach is the right move. Proves they don't need it. Makes me wonder what other "essential" permissions in these tools are just there to make their support engineers' lives easier at our expense.

Exactly. That audience part is what turns a minor risk into a huge one. A scoped token to just the kube-apiserver is useless anywhere else, even if leaked. A default token is a skeleton key.

>prioritized a one-line Helm install
That's it, right there. Their security model is an afterthought to their GTM strategy.

A webhook is the right call. We found the same thing with their sidecar injector. It doesn't need the default token either, but they mount it because it's easier than coding a proper client.

Yikes, that default ClusterRole is nuts. It's basically giving a monitoring tool the keys to the whole kingdom.

I'm trying to get better at reading these YAML files myself. When you see "list, get, and watch on nearly every resource," does that usually include custom resources from other operators too? Like, if I have a database operator installed, could it see those objects?

You're spot on about the chain. I've seen this pattern with integration platforms too, where an overly permissive API key gets logged by a poorly configured debugging step in a Zapier task, or ends up in a Workato recipe's output sent to an unsecured channel. The initial exposure feels minor, but the downstream impact is massive because the credential itself is so powerful.

It's the same root cause: the default credential is designed for maximum vendor convenience, not minimum necessary access. This turns any trivial misstep into a critical incident.

Great catch on the audit report. It's not just a permissions problem, it's a support cost problem for them.

When they design it with a skeleton key, they eliminate thousands of support tickets from customers whose restricted roles break a niche feature. They push the security and management burden entirely onto the customer. The liability is transferred.

You'll see this baked into their pricing model too. Their "enterprise" tier is often just the same software with a checkbox to disable the overly permissive defaults. You're literally paying extra to turn off a security risk they created.

>You're literally paying extra to turn off a security risk they created.

This is so true, and it's frustrating how common it is. It's not just their support cost, it becomes a sales feature. The rep on the call literally said, "Our enterprise plan includes granular RBAC controls," when I asked about restricting the service account. You're right, they're selling you the solution to the problem they built in.

I see this in marketing automation too. The "growth" tier lets you send bulk email, but you need "enterprise" to actually set meaningful rate limits or require double opt-in. You're paying more for the ability to *not* spam your list. Same pattern.

I saw the report's mention of the token being exfiltrated from the API endpoint. That's a huge escalation from just having broad permissions.

In Salesforce, I've seen similar where a poorly scoped integration user's session ID can be pulled from a debug log and used elsewhere. It feels like the same oversight - they assume the credential is safe just because it's in the pod.

Do you know if the report suggested any immediate detection tactics for that token exfiltration, besides locking down the role? Something like monitoring for unusual API calls from the agent's service account?

That's the core issue, it is lazy. But disabling it in the pod spec isn't a fix, it just breaks the install because they haven't built a client that works without it. The vendor's entire auth model is predicated on that default token mount existing.

You're right they should be forced to use a proper client. The problem is they won't until customers reject the default and walk away. As long as the one-line install works, they have zero incentive.

That's exactly the kind of thing I've been paranoid about as we start testing these platforms. When you say they can exfiltrate the token from a well-known API endpoint, does that mean it's something a compromised app could do automatically, or would it require manual steps from an attacker?

It can be a bit of a step up from basic RBAC, but it's a fantastic learning tool because you're working with live policy. I'd say set up a test cluster and try it. You'll break things, but that's how you learn what "patch" and "create" really mean for pods.

>Does the webhook break on every update from the vendor, though?
Sometimes, yeah. That's the trade-off. I've had a webhook reject a new pod spec because the vendor changed a label selector in their manifest and my rule was too strict. It's a temporary headache, but it beats the panic tax any day. You just tweak the rule and move on.