Claims and Service Offerings are a proposed optional module for requesting an OpenBao service without exposing the
entire OpenBaoCluster workload specification to every tenant.
Intended model
- A platform operator defines an approved offering and the parameters a tenant may choose.
- A tenant submits a small claim that selects an offering.
- The module validates the tenant, offering revision, and exposed parameters.
- It renders a deterministic, claim-owned
OpenBaoCluster. - It projects useful cluster state and connection information back to the claim.
The concrete cluster remains visible and operator-managed. Claims do not replace the direct lifecycle API.
Module contract
| Concern | Proposed boundary |
|---|---|
| API ownership | Module resources use an independently versioned claims.openbao.org group |
| Dependency direction | Claims can consume stable core contracts; core packages cannot depend on the Claims module |
| Installation | The lifecycle core starts and reconciles without Claims CRDs or controllers |
| Materialization | A claim creates a deterministic, ownership-marked OpenBaoCluster in the same cluster |
| Failure mode | Unsupported or unsafe shapes block with status instead of silently weakening the service |
Security boundary
- Tenant namespace access still requires explicit onboarding.
- A non-controller identity cannot spoof or mutate claim ownership markers.
- Connection output remains bound to the claim’s custody boundary.
- Dependencies use explicit references instead of broad discovery.
- Secret values stay out of CRDs, status, logs, and Events.
- Ordinary claim edits do not trigger hidden adoption, replacement, or data migration.
Initial non-goals
- importing unmanaged OpenBao clusters;
- adopting a directly managed cluster during ordinary reconciliation;
- exposing arbitrary low-level workload fields through a claim;
- managing auth methods, policies, engines, or audit devices continuously after bootstrap; or
- moving secret values between clusters.
The design can move into current documentation only after its API packages, generated CRDs, installation wiring, admission, architecture rules, and lifecycle tests land together.