Spec/module: KubernetesOpenBao — spec.proto + both IaC modules (a new pattern: post-deploy reconciliation).
Problem. A fresh OpenBao serves no secrets engines, no policies, and no auth methods — all of it is runtime API configuration with no declared-state home in the component:
- Consumer applications correctly hold no
sys/ capability (least privilege), so they can never self-heal a missing mount or policy.
- A fresh environment or a vault rebuild silently starts unbootstrapped: every platform vault call fails with
no handler for route until a human runs a runbook.
- Planton's own platform already treats this as provisioning: the planton-operator idempotently ensures the KV v2 + Transit mounts after unseal (
product/services/operator/internal/bootstrap/openbao.go — "Enabling engines is infrastructure provisioning and therefore the operator's job, never the control plane's"). Consumers of the public component have no operator, so each must reinvent that logic or stay manual.
- Precedent in the repo:
kubernetespostgres declares bootstrap (initdb / post_init_sql) and delegates execution to the CloudNativePG operator. OpenBao has no operator to delegate to — the component is the only provisioning-chain home.
Requested change. A declared bootstrap stanza, shape illustrative:
message KubernetesOpenBaoBootstrap {
repeated KubernetesOpenBaoEngineMount engine_mounts = 1; // path + type (+ options, e.g. kv version=2)
repeated KubernetesOpenBaoPolicy policies = 2; // name + policy HCL
KubernetesOpenBaoKubernetesAuth kubernetes_auth = 3; // enable + roles (bound SA/namespace, ttl)
}We deliberately do not prescribe the execution mechanism (module-rendered idempotent Job with a user-supplied root-token Secret reference, or a generalization of your operator's bootstrap into the component). Requirements regardless of mechanism: idempotent, re-converges after a vault rebuild, the root token never lands in the config ConfigMap, and nothing grants sys/ to application tokens.
Our workaround until then: an idempotent manual runbook plus an in-app behavioral canary (the app round-trips KV + Transit on a schedule and alerts on failure/silence), so drift is loud even though provisioning stays manual. Filed from stigmer/stigmer-cloud#221.
Spec/module:
KubernetesOpenBao—spec.proto+ both IaC modules (a new pattern: post-deploy reconciliation).Problem. A fresh OpenBao serves no secrets engines, no policies, and no auth methods — all of it is runtime API configuration with no declared-state home in the component:
sys/capability (least privilege), so they can never self-heal a missing mount or policy.no handler for routeuntil a human runs a runbook.product/services/operator/internal/bootstrap/openbao.go— "Enabling engines is infrastructure provisioning and therefore the operator's job, never the control plane's"). Consumers of the public component have no operator, so each must reinvent that logic or stay manual.kubernetespostgresdeclares bootstrap (initdb/post_init_sql) and delegates execution to the CloudNativePG operator. OpenBao has no operator to delegate to — the component is the only provisioning-chain home.Requested change. A declared bootstrap stanza, shape illustrative:
We deliberately do not prescribe the execution mechanism (module-rendered idempotent Job with a user-supplied root-token Secret reference, or a generalization of your operator's bootstrap into the component). Requirements regardless of mechanism: idempotent, re-converges after a vault rebuild, the root token never lands in the config ConfigMap, and nothing grants
sys/to application tokens.Our workaround until then: an idempotent manual runbook plus an in-app behavioral canary (the app round-trips KV + Transit on a schedule and alerts on failure/silence), so drift is loud even though provisioning stays manual. Filed from stigmer/stigmer-cloud#221.