feat(openbao): declare the platform PKI and transit CRs in Git #750

Merged

binjovi-bot merged 1 commit from feat/openbao-platform-raw into trunk

2026-09-14 16:11:27 +00:00

sean commented

2026-09-14 15:54:44 +00:00

Owner

What

Flatten the OpenBao slice of the XPlatform composite into plain Flux raw manifests. Ten CRs in ns openbao: the shared OpenBaoConnection, the root and internal PKI backends with their CAs, three issuing OpenBaoPKIRoles, the transit backend that holds the cosign image-signing keys, and the cosign-signer policy.

This is the same move that took the OpenBao server out of Crossplane on 2026-06-10 (infrastructure/openbao), one tier up. That one extracted the server; this extracts what the server holds.

Why

Step 1 of retiring Crossplane. Ordering that a composition implies becomes ordering that Git states. Per AGENTS.md, work that makes the cold-boot path simpler counts as progress toward the north star, and is verified by fidelity to live state rather than by a rebuild.

Nothing changes in the cluster

Crossplane still owns these CRs. Flux now also declares them. Both write the same bytes.

Evidence the copy is faithful -- server-side apply dry run as the field manager Flux will really use, no conflict on all ten, both as loose files and as rendered output:

kubectl apply --server-side --field-manager=kustomize-controller \
  --dry-run=server -f kubernetes/flux/infrastructure/openbao-platform/

Specs are verbatim. Only runtime fields are removed: status, ownerReferences, managedFields, operator finalizers, and the Crossplane composition-resource-name annotation. The provenance that annotation carried now lives in comments in kustomization.yaml, where it survives the retirement that will stop Crossplane setting it.

prune: false, deliberately

The OpenBaoConnection is composed inside a Crossplane Object whose spec.deletionPolicy is Delete. Retiring the XR today would delete the CR that every other CR here points at. That is the one real hazard, and it is why the handover has an ordered sequence in the directory README:

Declare (this PR) -- nothing changes
Flip that Object to Orphan
Retire the XR
Soak
Only then prune: true

Sharp edge

09-transitbackend declares cosign, cosign-ec and binjovi-forgejo-jwt. The build pipeline signs images with those keys. Every CR keeps spec.deletionPolicy: Retain; the CRD default is Delete.

Tests

tests/check.sh exits 0.

https://claude.ai/code/session_01GfkEuwuvGSqGyXVuxwT7PA

## What Flatten the OpenBao slice of the `XPlatform` composite into plain Flux raw manifests. Ten CRs in ns `openbao`: the shared `OpenBaoConnection`, the root and internal PKI backends with their CAs, three issuing `OpenBaoPKIRole`s, the transit backend that holds the cosign image-signing keys, and the cosign-signer policy. This is the same move that took the OpenBao **server** out of Crossplane on 2026-06-10 (`infrastructure/openbao`), one tier up. That one extracted the server; this extracts what the server holds. ## Why Step 1 of retiring Crossplane. Ordering that a composition implies becomes ordering that Git states. Per `AGENTS.md`, work that makes the cold-boot path simpler counts as progress toward the north star, and is verified by fidelity to live state rather than by a rebuild. ## Nothing changes in the cluster Crossplane still owns these CRs. Flux now also declares them. Both write the same bytes. Evidence the copy is faithful -- server-side apply dry run as the field manager Flux will really use, no conflict on all ten, both as loose files and as rendered output: ``` kubectl apply --server-side --field-manager=kustomize-controller \ --dry-run=server -f kubernetes/flux/infrastructure/openbao-platform/ ``` Specs are verbatim. Only runtime fields are removed: `status`, `ownerReferences`, `managedFields`, operator finalizers, and the Crossplane `composition-resource-name` annotation. The provenance that annotation carried now lives in comments in `kustomization.yaml`, where it survives the retirement that will stop Crossplane setting it. ## prune: false, deliberately The `OpenBaoConnection` is composed inside a Crossplane `Object` whose `spec.deletionPolicy` is **`Delete`**. Retiring the XR today would delete the CR that every other CR here points at. That is the one real hazard, and it is why the handover has an ordered sequence in the directory README: 1. Declare (this PR) -- nothing changes 2. Flip that `Object` to `Orphan` 3. Retire the XR 4. Soak 5. Only then `prune: true` ## Sharp edge `09-transitbackend` declares `cosign`, `cosign-ec` and `binjovi-forgejo-jwt`. The build pipeline signs images with those keys. Every CR keeps `spec.deletionPolicy: Retain`; the CRD default is `Delete`. ## Tests `tests/check.sh` exits 0. https://claude.ai/code/session_01GfkEuwuvGSqGyXVuxwT7PA

sean added 1 commit

2026-09-14 15:54:44 +00:00

feat(openbao): declare the platform PKI and transit CRs in Git

binjovi/ci Binjovi completed the frozen plan

Details

8f79ed95b6

Flatten the OpenBao slice of the XPlatform composite into plain Flux raw
manifests, the same move that took the OpenBao server out of Crossplane on
2026-06-10, one tier up. Ten CRs in ns openbao: the shared OpenBaoConnection,
the root and internal PKI backends with their CAs, the three issuing PKI
roles, the transit backend that holds the cosign image-signing keys, and the
cosign-signer policy.

Nothing in the cluster changes. Crossplane still owns these CRs and Flux now
declares the same bytes, so both write identical content. A server-side apply
dry run as field manager kustomize-controller reports no conflict on all ten,
both as loose files and as rendered output. That is the evidence the copy is
faithful.

The specs are verbatim. Only runtime fields are removed: status,
ownerReferences, managedFields, the operator finalizers, and Crossplane's
composition-resource-name annotation. The provenance that annotation carried
now lives in comments in kustomization.yaml, where it survives the retirement
that will stop Crossplane setting it.

prune is false. The OpenBaoConnection is composed inside a Crossplane Object
whose deletionPolicy is Delete, so retiring the XR today would delete the CR
that every other CR here points at. The directory README records that hazard
and the ordered handover: flip that Object to Orphan, retire the XR, soak,
and only then prune.

Claude-Session: https://claude.ai/code/session_01GfkEuwuvGSqGyXVuxwT7PA