Version. Helm chart 0.1.2. Checked 2026-09-29 against helm show values.
Observed. The chart's ConfigMap values carry CA bundles only. There is no value that mounts a sandbox policy from a ConfigMap into the gateway, so the policy cannot be managed the way every other Kubernetes config is managed (GitOps-applied ConfigMap, drift-checked, rolled back with the release).
Why it matters. Policy is the security boundary. On Kubernetes the natural source of truth is a ConfigMap owned by the platform team; without a mount point the policy has to reach the gateway through the API at runtime (per-sandbox --policy, or policy set --global, which has its own problem on the k8s driver), and an auditor cannot read the enforced policy from the cluster.
Ask. A chart value, e.g. server.policy.configMapName + server.policy.key, that mounts the ConfigMap and has the gateway load it as the default sandbox policy on start and on change.
Related: #4299 reports that policy set --global breaks sandbox start on the Kubernetes driver.
Version. Helm chart 0.1.2. Checked 2026-09-29 against
helm show values.Observed. The chart's ConfigMap values carry CA bundles only. There is no value that mounts a sandbox policy from a ConfigMap into the gateway, so the policy cannot be managed the way every other Kubernetes config is managed (GitOps-applied ConfigMap, drift-checked, rolled back with the release).
Why it matters. Policy is the security boundary. On Kubernetes the natural source of truth is a ConfigMap owned by the platform team; without a mount point the policy has to reach the gateway through the API at runtime (per-sandbox
--policy, orpolicy set --global, which has its own problem on the k8s driver), and an auditor cannot read the enforced policy from the cluster.Ask. A chart value, e.g.
server.policy.configMapName+server.policy.key, that mounts the ConfigMap and has the gateway load it as the default sandbox policy on start and on change.Related: #4299 reports that
policy set --globalbreaks sandbox start on the Kubernetes driver.