Support opt-in Kubernetes service account token automount for sandbox pods

[RohanAdwankar]

Problem Statement

OpenShell's Kubernetes driver currently hardcodes sandbox pods with:

automountServiceAccountToken: false

That is a good secure default, but it prevents operators from using Kubernetes' standard in-cluster authentication model when a sandbox intentionally needs Kubernetes API access.

For integrations like OpenClaw, the agent may need to run read-only kubectl commands inside the sandbox, using a tightly scoped sandbox service account. Today that requires deployment-specific workarounds such as seeding kubeconfig/token material into the sandbox. That is harder to operate and less idiomatic than letting Kubernetes mount the service account token for the configured sandbox service account.

The desired behavior is not to grant Kubernetes access by default. The desired behavior is to let operators explicitly opt in, then rely on normal Kubernetes RBAC to constrain what the sandbox can do.

Proposed Design

Add an explicit Kubernetes driver configuration field:

[openshell.drivers.kubernetes]
automount_service_account_token = false

Default behavior remains unchanged: sandbox pods do not receive Kubernetes service account tokens.

When set to true, the Kubernetes driver should render sandbox pods with:

spec:
  automountServiceAccountToken: true

The Helm chart should expose the same option:

server:
  sandboxAutomountServiceAccountToken: false

This allows deployments that need sandbox-local kubectl to configure:

server:
  sandboxServiceAccountName: openshell-sandbox
  sandboxAutomountServiceAccountToken: true

and then bind that service account with least-privilege RBAC, for example read-only access to selected resources:

rules:
  - apiGroups: [""]
    resources: ["pods", "pods/log", "services", "configmaps", "events"]
    verbs: ["get", "list", "watch"]

Security properties:

• Default remains hardened: false.
• Enabling the flag does not grant permissions by itself.
• Kubernetes RBAC remains the source of authorization.
• Operators can scope the sandbox service account per namespace/deployment.
• The existing OpenShell bootstrap/projected token remains separate from Kubernetes API access.

Alternatives Considered

Could seed kubeconfig/token material into the sandbox workspace. This works, but it is deployment-specific and requires extra secret/file handling outside Kubernetes' normal in-cluster auth path. It also makes rotation and RBAC ownership less clear.

Agent Investigation

No response

Checklist

• I've reviewed existing issues and the architecture docs
• This is a design proposal, not a "please build this" request

[johntmyers]

For integrations like OpenClaw, the agent may need to run read-only kubectl commands inside the sandbox, using a tightly scoped sandbox service account.

Is there a concrete use case for this?

[RohanAdwankar]

yes i can message on slack