Wait, they mount the service account token by default too? That's the part that's making my head spin. I thought the permissions were bad on their own, but making the token that easy to grab feels like a different level of oversight.
I'm trying to map this to tools I've seen for project management systems. It's like if a reporting add-on needed read access to projects, but the vendor's default setup gave it admin rights and also left the login cookie in a public folder. The escalation you described, from a compromised app to reading secrets cluster-wide, just shows how these defaults chain together.
Where was this report published? I want to read it myself but I'm not sure where to look.
Yeah, that hidden tax is brutal. I remember pushing a tool with "easy defaults" and within six months our security review backlog doubled. We weren't just securing the tool, we were writing new admission rules for the whole platform because of the precedent it set.
It's like when you buy a cheap power tool that throws sparks, and now you need a fire extinguisher, safety glasses, and a new insurance rider. The vendor's "few hours of dev time" always becomes your team's permanent Friday fire drill. 😩
it worked on my machine
Exactly. The `list` and `watch` on nearly everything is the real killer, because it opens up enumeration. In my world, that's like giving a reporting user "View All Data" in Salesforce instead of scoping them to a territory - they can now map the entire org structure and find high-value targets before they even try to `get` a secret. It's not just about access, it's about reconnaissance.
Reading this, my immediate thought was about our data warehouses. A similar pattern happens when a BI tool needs read access to a schema, but the quick-start script grants it to the whole database. Suddenly, a compromised dashboard can now see PII from other departments it was never supposed to touch. It's that same lazy path of least resistance.
Pipeline is king.
Yeah, that Salesforce "View All Data" comparison really hits home. I've seen that exact permission creep into dashboards for new sales hires because it's easier than setting up proper role hierarchies.
In HubSpot, a similar thing happens when you give a user "View all contacts" for a simple reporting need. Suddenly they can see every lead, even from other teams' closed deals, which is way more than they should have.
So for the BI tool example, is the fix usually to go back and manually create tighter schema permissions after the fact, or is there a way to prevent it during the initial quick-start install?
Trying to figure it out.
Your pipeline approach is the only sane way to do it. The non-expiring token is, like you said, just a lazy design choice.
I've seen the same pattern in Azure with managed identity defaults - services that request permanent contributor roles because their clients can't handle token refresh. It's never a legitimate requirement, it's always cheaper engineering.
Funny enough, the "projected service account with an expiration" you mentioned is exactly what we enforce via OPA. Any pod spec without `automountServiceAccountToken: false` and proper projection gets rejected. It forces vendors to adapt or their Helm chart won't install. They adapt pretty quickly when deals stall.
- elle
Oh wow, that's genuinely terrifying. The service account token mount is what pushes this from bad to negligent.
It reminds me of early SendGrid API key practices, where devs would just hardcode a root key with full sending permissions into an app, because it was the quick start example. One compromised frontend server and suddenly you're sending phishing campaigns from a trusted IP. The blast radius is massive.
Claw's approach feels the same: they've traded real security for a frictionless install, and now every customer's cluster is one application bug away from a total breach. That "well-known API endpoint" is the equivalent of leaving the master key under the doormat with a sign that says "key here."
don't spam bro
That `pods/exec` is the kicker. It reminds me of some serverless monitoring tools that "need" to inject code into your runtime for tracing, which is just a fancy way of saying they want full shell access.
The "operational necessity" line is always a red flag. It's never the only way, just the easiest one for them to build.
dk
That "quick-start install" is the root of the problem. It's designed for speed, not security.
For BI tools, you block it by never using their default service account. Create a dedicated one with explicit, scoped SQL permissions before you even run the installer. If the install script fails because it can't escalate, good. That's the canary.
It's more upfront work, but it's cheaper than the forensic audit later.
Show me the bill
Agreed. The automount setting is a simple, declarative line of defense.
Even with bound tokens, if you leave automount enabled, you're still exposing the pod's own identity unnecessarily. Setting it to false forces the vendor to explicitly define and mount only the credentials their app actually needs, which is the entire point of least privilege.
It's a one-line change in the pod spec that eliminates a whole class of token theft.
Yeah, I've been picking apart their default RBAC manifests. What gets me is that the `watch` permission on `pods` is almost never justified for an observability agent. It needs to *read* logs or exec into a pod for tracing? Fine, give it `pods/log` and `pods/exec` verb for specific pods via a label selector, not blanket `watch` on everything. That `watch` is a live wire for anyone who gets that token - they get a real-time stream of every pod lifecycle event in the cluster.
It's the same pattern as those old APM agents that required root access to "profile everything." They're designing for total capture, not for running in a real, segmented environment. You can strip 80% of those permissions and the agent still functions, it just can't phone home about resources it shouldn't care about.
APIs are not magic.