Provision the tenant boundary before any cluster exists.
Day 0 is the namespace and tenancy setup phase. The provisioner controller takes an OpenBaoTenant request, applies tenant-scoped RBAC and policy defaults, and leaves behind a namespace that is safe for later OpenBaoCluster creation.
At a glance
Starts with
OpenBaoTenantcreation and target namespace selection- operator ServiceAccount identity and tenant policy defaults
- admission dependencies that must exist before Secret access is widened
Primary owners
- internal/controller/provisioner
- internal/app/provisioner
- internal/service/provisioner
Writes
- tenant Role and RoleBinding resources
- Secret reader and writer allowlist roles
- Pod Security labels plus optional ResourceQuota and LimitRange defaults
Hands off to
- a namespace that is ready for
OpenBaoClustercreation - tenant operators who can now move into Day 1 cluster creation
- later Secret allowlist sync as clusters appear or disappear
Architectural Placement
Day 0 provisioning uses the dedicated tenant-controller path:
- A cluster admin or namespace owner creates
OpenBaoTenant. internal/controller/provisionerreceives the reconcile event and delegates intointernal/app/provisioner.internal/service/provisionerapplies namespace-scoped RBAC, policy labels, allowlists, and quota defaults.
This keeps tenant onboarding separate from steady-state cluster reconciliation and makes the tenant boundary explicit before any workload resources exist.
Diagram
Day 0 provisioning flow
Provisioning establishes the namespace boundary first, then keeps Secret access aligned with the managed clusters that later appear in that namespace.
Reference table
Day 0 responsibilities
| Stage | Primary owner | Why it matters |
|---|---|---|
| Namespace targeting | Provisioner controller and app layer. | Tenant provisioning must decide which namespace is allowed before any RBAC or policy defaults are applied. |
| Operator tenant RBAC | Provisioner manager. | The operator needs enough namespace-scoped access to manage OpenBao resources there without defaulting to broad cluster-wide permissions. |
| Secret allowlists | Provisioner manager plus tenant Secret RBAC sync. | Multi-tenant safety depends on explicit Secret access derived from actual managed cluster references. |
| Policy defaults | Provisioner manager. | Pod Security labels and optional quotas give the namespace a safe baseline before a cluster is created. |
Reference table
Safety boundaries
| Concern | Provisioning behavior |
|---|---|
| Self-service namespace scope | Self-service tenants may target only their own namespace; cross-namespace provisioning is reserved for trusted centrally managed cases. |
| Admission readiness | Tenant Secret allowlists wait for admission-policy dependencies so Secret access is not widened before enforcement is available. |
| Shared RBAC lifecycle | Tenant RBAC avoids OwnerReferences that would let a single cluster deletion garbage-collect shared namespace permissions. |
| Cleanup timing | Provisioned RBAC remains in place until managed clusters are gone, then the tenant finalizer can be released safely. |
Continue the lifecycle
This version tracks a prerelease build. Features and behavior may change before the next stable release.
Was this page helpful?
Use Needs work to open a structured GitHub issue for this page. The Yes button only acknowledges the signal locally.