feat(openbao): central platform instance and per-tenant transit provisioning - #4177

What this PR does

Phases 1 and 2 of #2787, the platform side of tenant OpenBAO auto-unseal. Two commits: the central instance, and the reconciler that provisions per tenant against it. The tenant half is not here, see the bottom.

Worth knowing before reading the diff, because it is why a new package exists at all: packages/system/openbao has never been a running instance. Its component carries no install section, and package_reconciler.go creates a HelmRelease only for components that have one, so nothing ever stood it up. It is the workload chart a tenant OpenBAO renders from, published for that purpose and nothing else, which is why its values are a five line stub. The platform instance therefore gets its own package rather than being loaded into that one.

packages/system/openbao-central is HA raft over cert-manager issued TLS, with a Shamir seal because no cloud KMS is assumed on bare metal. A one time init Job persists the unseal keys and root token, a long running unsealer re-unseals pods after a restart, and a setup Job enables the transit engine and kubernetes auth that the per-tenant seals will use. It wraps the same published chart artifact a tenant instance uses instead of vendoring the upstream chart a second time, so one make update in packages/system/openbao moves both consumers and they cannot drift to different upstream versions.

Naming there is load-bearing and nothing in Go checks it: the reconciler reaches this instance at https://openbao-system.cozy-openbao.svc:8200 and reads openbao-system-keys and openbao-system-ca from cozy-openbao. central_test.yaml pins the naming, the https scheme, the apiserver egress label and the raft topology, so a values edit turns into a red test instead of broken tenant provisioning.

Replicas default to 3 and go down to 1, which a single node install needs. Raft stays the backend at every count, including 1: the backend a barrier was created under cannot be changed afterwards, so scaling 1 to 3 has to be an in-place addition of voters rather than a file to raft migration nobody can perform. At one replica the retry_join set is omitted, because a lone node would retry a self join it cannot complete until the init Job promotes it, and the upstream chart's REQUIRED hostname anti-affinity is dropped, which is the other half of why a single node schedules at all. Rendering at 3 replicas is byte identical to the hardcoded config it replaces.

The instance also carries policy.cozystack.io/allow-to-apiserver. It runs service_registration "kubernetes", and without that label cozystack's CiliumNetworkPolicy does not admit the egress, so the pods hang at startup with the listener open and nothing answering (#2793).

The reconciler watches inner OpenBAO HelmReleases labelled apps.cozystack.io/transit-unseal and ensures, per instance, a transit key, an unseal policy scoped to that key, and a kubernetes-auth role bound to the instance's server ServiceAccount. It then publishes the central CA as the <name>-transit-ca ConfigMap, a public certificate rather than a Secret. No token is minted or delivered: the instance exchanges its own projected ServiceAccount token for a transit token at every boot, so there is no long-lived credential in the tenant namespace to store, rotate or leak. Nothing emits that label yet, so the reconciler is inert until the tenant chart grows a transit seal.

One cost to be explicit about rather than discover later: this installs a platform OpenBAO on every paas install, and with the tenant default in the next PR being the transit seal it cannot be made opt-in without breaking that default. Three replicas is the default and one is supported, so a small install can pay less, but it does pay something.

Not in this PR, and deliberately: the tenant seal stanza, the auto-init Job on the tenant side, the migration that pins existing instances, and the e2e. Those are the next PR, which also needs #4168 for the seal.type enum it extends with a third value.

Verified: make unit-tests green on this branch, go build ./... and go test ./internal/operator/... clean, the central package renders at 1, 3 and 5 replicas and refuses 0, and the new suite was mutation checked (turning TLS off, keeping the anti-affinity at one replica and allowing a self join each turn a test red).

Screenshots

No UI change.

Downstream repositories

Walked the trigger map in docs/agents/contributing.md against the diff. One hit, left unticked because the follow-up is not filed yet and I would rather a human decide whether it belongs on next now or with the tenant half: this adds a platform component, which the map routes to the website's content/en/docs/next/guides/platform-stack/_index.md and operations/configuration/licenses.md.

Nothing else matches. The package is under packages/system/, not packages/apps/ or packages/extra/, so no reference page is generated for it and the website Makefile app lists are unaffected. No app values.schema.json, no ApplicationDefinition, no release.prefix, no version enum and no hand-typed CRD changed, so terraform-provider-cozystack has nothing to mirror. packages/core/installer/values.yaml, the platform variants and the node prerequisites are untouched, so ansible-cozystack is unaffected. The packages/{apps,system,extra,core} split, the hack/ layout and the cozy-* namespace names are unchanged, so ccp keeps its anchors.

• No downstream repository is affected by this change
• cozystack/website - follow-up:
• cozystack/terraform-provider-cozystack - follow-up:
• cozystack/ansible-cozystack - follow-up:
• cozystack/ccp - follow-up:
• cozystack/talm - follow-up:
• cozystack/cozyhr - follow-up:
• cozystack/cozy-proxy - follow-up:
• cozystack/cozystack-telemetry-server - follow-up:
• cozystack/external-apps-example - follow-up:
• cozystack/examples - follow-up:
• cozystack/community - follow-up:

Release note

feat(openbao): the platform now runs a central OpenBAO (`packages/system/openbao-central`) in `cozy-openbao`: HA raft over cert-manager TLS, Shamir seal with automatic init and re-unseal, and a transit engine that tenant instances will use for auto-unseal. Replicas default to 3 and are configurable down to 1 for single-node installs. The cozystack operator provisions a transit key, a scoped unseal policy and a kubernetes-auth role per tenant instance, and publishes the central CA as a ConfigMap, so no unseal token is ever stored in a tenant namespace.