Provision tenant namespaces with scoped RBAC, Secret allowlists, and policy defaults.
The provisioner manager owns the tenant-onboarding contract for OpenBaoTenant. It creates namespace-scoped permissions for the operator, applies Pod Security and quota defaults, and keeps Secret access narrowed to explicit allowlists derived from managed clusters.
At a glance
Control path
- dedicated OpenBaoTenant controller
- internal/app/provisioner
- internal/service/provisioner
Owns
- tenant-scoped operator Role and RoleBinding resources
- reader and writer Secret allowlists derived from tenant clusters
- Pod Security labels plus optional ResourceQuota and LimitRange defaults
Writes
- tenant Role / RoleBinding and Secret RBAC resources
- namespace labels that enforce Pod Security defaults
- ResourceQuota and LimitRange resources from OpenBaoTenant.spec
Depends on
- OpenBaoTenant namespace targeting rules and resource policies
- admission dependencies before tenant Secret RBAC sync can proceed
- current OpenBaoCluster objects that still exist in the tenant namespace
Architectural Placement
Provisioning follows a dedicated tenant-controller path:
internal/controller/provisionerreceives the reconcile event forOpenBaoTenant.- The controller delegates orchestration to
internal/app/provisioner. - The app layer invokes
internal/service/provisionerto apply RBAC, labels, allowlists, and cleanup behavior.
That keeps tenant onboarding separate from OpenBaoCluster steady-state reconciliation while still using the same design system and policy language.
Reference table
Owned surfaces
| Surface | What the manager decides | Why it matters |
|---|---|---|
| Tenant RBAC | The operator ServiceAccount permissions granted in the tenant namespace. | The operator needs enough access to manage clusters there, but not broad namespace-level privileges by default. |
| Secret allowlists | Which Secrets the operator may read or write for managed clusters in the tenant namespace. | Multi-tenant safety depends on explicit Secret access instead of wildcard RBAC. |
| Pod Security labels | The baseline namespace policy applied to tenant workloads and operator-managed pods. | Tenants need a secure default even before any cluster objects are created. |
| Quota defaults | Optional ResourceQuota and LimitRange resources derived from OpenBaoTenant.spec. | Tenants need resource guardrails that travel with the namespace onboarding contract. |
Provisioning Flow
Diagram
Tenant onboarding flow
Provisioning applies namespace-scoped guardrails first, then keeps Secret allowlists synchronized as managed clusters appear or disappear in the tenant namespace.
Reference table
Security guardrails
| Concern | Manager behavior |
|---|---|
| Namespace targeting | Self-service tenants may target only their own namespace; cross-namespace provisioning is reserved for trusted operator-managed cases. |
| Admission dependencies | Tenant Secret allowlists wait for admission-policy dependencies so Secret access is not widened before enforcement is ready. |
| Shared RBAC lifecycle | Provisioned tenant RBAC avoids OwnerReferences that would let a single cluster deletion garbage-collect shared namespace permissions. |
| Secret scope | Reader and writer Secret Roles are derived from explicit cluster references instead of wildcard list or get access to every Secret in the namespace. |
Reference table
Deletion lifecycle
| Phase | Manager intent |
|---|---|
| Tenant marked for deletion | Keep provisioned RBAC in place while managed clusters still exist in the namespace. |
| Namespace emptied of managed clusters | Remove provisioned Role, RoleBinding, Secret allowlist roles, and default quota resources. |
| Finalizer removal | Only remove the tenant finalizer after namespace-scoped provisioning artifacts are cleaned up. |
Related deep dives
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.