Onboard a namespace

Authorize the controller to manage an existing namespace and verify the tenant guardrails and RBAC handoff.

Updated 9 August 2026 · 4 min read

On this page

OpenBaoTenant authorizes the controller to manage an existing namespace and applies tenant guardrails. It does not create the namespace or an OpenBaoCluster.

Skip this page only when the operator uses the verified single-tenant mode. Review tenant boundaries when you need the authority model behind this handoff.

Choose the onboarding owner

ModelWhere to create OpenBaoTenantAllowed customization
Self-serviceThe target namespacemetadata.namespace must equal spec.targetNamespace; uses default quota and LimitRange
Centrally managedThe rendered operator namespaceA platform administrator can target another namespace and set custom quota or LimitRange

The target namespace must already exist. spec.targetNamespace is required and admission treats it as immutable.

Onboard through self-service

  1. Create the target namespace if it does not exist.

    apply

    Create the evaluation namespace

    kubectl create namespace openbao-demo
  2. Save this request as tenant.yaml.

    configure

    Declare a self-service tenant

    apiVersion: openbao.org/v1alpha1
       kind: OpenBaoTenant
       metadata:
         name: openbao-demo
         namespace: openbao-demo
       spec:
         targetNamespace: openbao-demo
  3. Apply the request.

    apply

    Onboard the namespace

    kubectl apply -f tenant.yaml
  4. Verify that provisioning completed.

    verify

    Verify the tenant handoff

    kubectl -n openbao-demo get openbaotenant openbao-demo \
         -o jsonpath='{.status.provisioned}{"\t"}{.status.conditions[?(@.type=="Provisioned")].status}{"\n"}'
       kubectl -n openbao-demo get rolebinding \
         openbao-operator-tenant-rolebinding

    The first command must print true and True. The condition carries the current generation, reason, and message; the RoleBinding is the concrete handoff that allows cluster reconciliation to continue.

Onboard centrally

Create the request in the actual rendered operator namespace when a platform administrator manages onboarding for a team:

configure

Declare a centrally managed tenant

apiVersion: openbao.org/v1alpha1
kind: OpenBaoTenant
metadata:
  name: team-a
  namespace: openbao-operator-system
spec:
  targetNamespace: team-a-prod
  # Optional platform-managed values:
  # quota:
  # limitRange:

The trusted namespace is the rendered operator namespace, not a fixed project-wide value. If the release uses another namespace, change metadata.namespace accordingly.

Understand the applied resources

Onboarding manages:

  • the namespace-scoped controller Role and openbao-operator-tenant-rolebinding;
  • Secret allowlist Roles used by operator-managed workloads and Jobs;
  • a ResourceQuota and LimitRange;
  • restricted Pod Security enforce, audit, and warn labels by default.

It does not create workload NetworkPolicies. Those are reconciled after an OpenBaoCluster is accepted. The explicit OpenBaoTenant request also means the Provisioner does not need to discover tenant namespaces through a cluster-wide namespace label watch.

The default quota allows 50 Pods, 20 requested CPU, 64 GiB requested memory, 40 CPU limit, and 128 GiB memory limit. The default per-container LimitRange is:

ResourceDefault requestDefault limit
CPU100m500m
Memory128Mi512Mi

Set tenancy.namespacePodSecurityLabels.mode=external when another platform controller owns the Pod Security labels. This delegates only label mutation; the operator still manages tenant RBAC, Secret allowlists, quota, and LimitRange.

Apply tenant and cluster together

GitOps can apply OpenBaoTenant and OpenBaoCluster in one synchronization. The cluster controller pauses until openbao-operator-tenant-rolebinding exists, then continues without treating the missing handoff as a permanent failure. Watching the tenant status first still gives the clearest rollout signal.

Troubleshoot onboarding

SymptomLikely causeCheck first
Security violationA self-service request targets another namespacemetadata.namespace and spec.targetNamespace
status.provisioned stays false with namespace-not-foundThe target namespace does not existNamespace name and platform provisioning
Cluster keeps waiting after the tenant is trueThe handoff RoleBinding is absent or wrongopenbao-operator-tenant-rolebinding and its subject
Namespace label update is unauthorizedAnother policy layer owns labelsSet Pod Security label mode to external after review
Custom quota is ignoredThe request used self-serviceCreate the request in the operator namespace through the platform path
Admission dependency errorsRequired policies or bindings are not readyOperator installation and admission-policy status

Remove or retarget a tenant

You cannot change spec.targetNamespace in place. Before deleting an OpenBaoTenant, delete every OpenBaoCluster in the target namespace; the finalizer waits until they are gone.

When no other active, authorized OpenBaoTenant claim targets the namespace, cleanup removes tenant RBAC and the operator-managed ResourceQuota and LimitRange before removing the finalizer. Another active claim preserves those shared resources while the deleting claim finalizes. Claim discovery and cleanup fail closed: an error keeps the finalizer in place.

Pod Security labels remain unchanged because the operator does not retain the namespace’s earlier label state. Review them explicitly when decommissioning or retargeting the namespace.

Continue with cluster creation.

Search the handbook

Try “install”, “threat model”, or “compatibility”.