Phase-4 infra installs from iter-12 diagnostic audit (37 of 41 e-blocked TCs covered):
bp-catalyst-platform 1.4.120 → 1.4.122 — Gitea client wired (cluster B, 4 TCs):
- catalyst-api Deployment now reads CATALYST_GITEA_URL + CATALYST_GITEA_TOKEN from `catalyst-gitea-token` Secret (mirrors blueprint-controller pattern).
- Unblocks /api/v1/sovereigns/.../blueprints/{publish,curatable,curate,edit-pr} which previously returned 503 "Gitea client unconfigured".
- TC-081, TC-082, TC-083, TC-085.
bp-netbird 0.1.0 → 0.1.1 + slot 53 install (cluster C, 4 TCs):
- Pinned image tags (netbirdio/management:0.34.0, signal:0.34.0, coturn:4.6.2) so chart renders without CI mirror cycle.
- Bootstrap-kit slot 53 enables NetBird on omantel; OIDC issuer points at the new omantel realm (Fix #53A).
- TC-281, TC-282, TC-283, TC-284.
bp-dmz-vcluster 0.1.0 → 0.1.1 + slot 54 install (cluster C, 3 TCs):
- Pinned upstream loft-sh/vcluster:0.20.0 tag.
- Bootstrap-kit slot 54 enables DMZ vCluster `omantel-dmz` on omantel.
- TC-286, TC-287, TC-288.
bp-cilium chart pin 1.2.0 → 1.3.0 + Hubble UI ingress + BGP (cluster C, 3 TCs):
- Hubble relay + UI enabled in omantel cilium overlay.
- catalystOverlay.hubbleUI block enables HTTPRoute hubble.console.omantel.biz; external-dns auto-creates the DNS record.
- bgpControlPlane.enabled=true for multi-region peering (TC-349).
- TC-289, TC-290, TC-349.
Total: 14 of the 25 cluster-C TCs covered + 4 cluster-B TCs.
|
||
|---|---|---|
| .. | ||
| templates | ||
| tests | ||
| Chart.yaml | ||
| README.md | ||
| values.yaml | ||
bp-netbird
Catalyst-authored Blueprint chart for NetBird — a WireGuard-based zero-trust mesh + remote-access overlay. Operators, engineers, and customer admins enroll devices via Keycloak SSO and reach Sovereign-internal services from any laptop or mobile device.
What ships
| Resource | Purpose |
|---|---|
Deployment/<rel>-management + PersistentVolumeClaim |
NetBird management API + UI; SQLite-backed state on hcloud-volumes PVC |
Deployment/<rel>-signal |
WebRTC signaling for WireGuard handshake brokering |
Deployment/<rel>-coturn |
TURN/STUN server for NAT traversal fallback |
Service/<rel>-{management,signal,coturn} |
ClusterIP fronts; coturn flips to LoadBalancer per Sovereign overlay |
HTTPRoute/<rel> |
Cilium Gateway exposure (mgmt UI + signal gRPC) |
NetworkPolicy/<rel>-management-egress |
Default-deny + selective egress to Keycloak / signal / coturn / NATS |
ConfigMap/bp-netbird-realm-patch |
catalyst.openova.io/keycloak-config: realm-patch — adds NetBird OIDC client + realm role |
SealedSecret/<oidc> + SealedSecret/<coturn-auth> |
Placeholders for OIDC client secret + coturn static-auth secret |
Default-OFF gate
netbird.enabled: false in values.yaml. helm template renders
zero resources by default. Operator opts in via per-Sovereign
overlay at clusters/<sovereign>/bootstrap-kit/<NN>-netbird.yaml once
the dependencies (bp-keycloak + bp-cilium + bp-sealed-secrets) are
ready.
SHA-pinned images
All three container images are upstream:
netbirdio/managementnetbirdio/signalcoturn/coturn
Per docs/INVIOLABLE-PRINCIPLES.md #4a, image.tag is empty in
values.yaml and the helm-template render fails-fast when a Sovereign
overlay leaves them empty (see _helpers.tpl::bp-netbird.imageRef). CI
populates the SHA tags via yq eval -i .image.tag = "<sha>" when
promoting a build into clusters/<sovereign>/.
Keycloak OIDC integration
The bp-netbird-realm-patch ConfigMap is consumed by bp-keycloak's
post-deploy keycloak-config-cli Job (sorted by name; the bp-
prefix groups Catalyst-owned patches together). It adds:
- the
netbirdOIDC client (confidential, withaudience-netbirdandgroupsprotocol mappers) - the
netbird-userandnetbird-adminrealm roles - default
netbird-usersandnetbird-adminsgroups bound to the matching realm roles
This mirrors the Guacamole pattern
from slice K+P+X1+G #1164. Two-step bootstrap: chart applies → operator
extracts the generated client-secret from KC admin API → kubeseal →
re-apply. The first user to land an OIDC handshake against the NetBird
management API becomes the account owner (per
oidc.adminUserIdClaim: sub).
Setup-key flow
NetBird's per-org join tokens (setup-keys) flow through the
catalyst-api → Keycloak OIDC chain for seamless onboarding. New
operators authenticate to NetBird via Keycloak SSO, request a
setup-key from the management UI (or via the catalyst-api REST
proxy under /api/v1/sovereigns/{id}/netbird/setup-keys), then enroll
their device with netbird up --setup-key <key> --management-url https://netbird.<sovereign-fqdn>.
NAT-traversal
The coturn Deployment defaults to ClusterIP. Per-Sovereign overlays
should flip netbird.coturn.service.type: LoadBalancer once the cloud
LB is available so peers behind symmetric NATs can reach the TURN
server from the public internet. The static-auth secret is shared with
the NetBird management Deployment via netbird-coturn-auth SealedSecret.
Tests
bash tests/render.sh exercises three contracts:
- Default-OFF: zero K8s resources rendered (CC3 default-OFF gate).
- Fail-fast on empty image tag: render aborts with the exact
bp-netbird: ... image tag is emptymessage whenenabled: truewithout a SHA stamp. - Full-ON canonical bundle: every required kind appears at least once and the realm-config wires the OIDC client.
helm lint clean.
See also
DESIGN.md— design rationale, Sovereign-mesh role, and ADR-0001 alignment.blueprint.yaml— Blueprint manifest (catalyst.openova.io/v1alpha1).- Guacamole pattern — the canonical Keycloak realm-config integration this chart mirrors.