Hi everyone! I’ve been trying to set up OpenClaw in our dev environment this week using their default Helm chart from the public repository. While I was testing, I stumbled onto something that seems really dangerous in the default configuration.
I’m still pretty new to Kubernetes and Helm, so I was following their docs exactly. I noticed that the chart’s default values.yaml has `serviceAccount.create` set to `true`, which is fine, but it also has `serviceAccount.automountServiceAccountToken` set to `true` by default. From what I’ve been learning about AppSec, this means the pod automatically gets the default service account token mounted, even if the app doesn’t need Kubernetes API permissions. Since the default service account often has overly permissive roles in many clusters, this feels like a major privilege escalation risk waiting to happen.
In our case, I confirmed the pod could list secrets in the namespace using that token. 😳
I’ve made a small patch to our local copy of the values. Here’s what I overrode:
```yaml
serviceAccount:
create: true
automountServiceAccountToken: false
```
And then, if your OpenClaw component actually *needs* Kubernetes API access (you'd know from errors), you should define a specific service account with limited RBAC roles and reference it explicitly.
I wanted to share this because the default chart is so widely used. For someone like me who’s just starting out, it’s easy to assume the defaults are secure. Has anyone else run into this? Is there a reason for this default that I’m missing? I’ve already submitted an issue to the OpenClaw project.
Thanks!