Kubernetes RBAC and multi-tenancy starts with a question of trust
A shared cluster is viable when RBAC, namespaces, resource quotas, network policy and admission controls are designed together as one tenancy model. Treated as separate settings configured by separate people at different times, they will drift apart, and the gaps between them become the places where one team can affect another. The starting question is not which objects to create but how much you trust each tenant, and what a tenant is allowed to do to the cluster itself. Namespaces alone are not a security boundary. They scope names and many namespaced objects, but they do not isolate everything a tenant can reach. Cluster-scoped objects such as Namespaces themselves, ClusterRoles, ClusterRoleBindings, CustomResourceDefinitions, PriorityClasses and StorageClasses are visible to every tenant that can read them. The kube-apiserver, the etcd store behind it, the nodes that run the pods and the shared control plane components are common to all tenants. A workload that escapes its container, or a principal with broad permissions, can reach resources that belong to other teams. For that reason, decide early which tenants are trusted with which privileges. Internal teams that share an organization and an on-call rotation carry a very different risk from unrelated business units, customers or third-party code. Write down who may create namespaces, who may read Secrets across namespaces, whether any tenant may run privileged pods or host networking, and who may change admission policy. Those answers determine whether a shared cluster is the right model or whether separate clusters are the better boundary. What makes this harder than it looks is that each control is an independent object that must agree with the others. A Role may be narrow while a RoleBinding grants it to a group that includes far more people than intended. A ResourceQuota can cap CPU while leaving Secrets readable. A NetworkPolicy can be correct in one namespace and absent in the next. A single broad ClusterRoleBinding, added to fix an urgent ticket, can undo the isolation that the other four controls were meant to provide. Confirm with your own environment which identity provider groups map to which bindings, and review every cluster-scoped grant as a standing risk rather than a one-time exception.
Which Kubernetes objects draw the tenant boundary
A shared cluster has no single tenancy switch. Namespaces, access bindings, quotas, network policies and admission labels each draw part of the boundary, and each one stops at a specific point. The cards below show what every object controls and what it leaves open, so you can check the gaps before you give a team its own slice of the cluster.
Namespaces as the unit of ownership
A namespace groups related objects and gives a team a scope for names, access and policy. It is the anchor the other objects attach to, so most tenancy designs start here. A namespace does not isolate compute, nodes, cluster-scoped resources such as Nodes, PersistentVolumes or CustomResourceDefinitions, or the API server itself. Check which objects each team can create outside its namespaces before you call a namespace a tenant.
Role and RoleBinding for namespace access
A Role grants verbs on resources inside one namespace, and a RoleBinding attaches that Role to users, groups or service accounts in the same namespace. Together they let a team manage its own workloads without seeing neighbors. They do not restrict what a subject can do against cluster-scoped resources, and they do not limit reads of Secrets unless you grant verbs on Secrets deliberately. Review each binding for list and watch on Secrets, which expose values to anyone who holds them.
ClusterRole and ClusterRoleBinding risks
A ClusterRoleBinding grants a role across every namespace, and a RoleBinding can also point at a ClusterRole to limit it to one namespace. Broad ClusterRoles, such as those that allow wildcard verbs or reads of Secrets cluster-wide, are the most common source of over-privilege in shared clusters. Default bindings, CI service accounts and operator installs often add them without review. Audit every cluster-scoped binding and confirm which group or account holds it.
ResourceQuota and LimitRange for capacity
A ResourceQuota caps total CPU, memory, storage and object counts within a namespace, so one team cannot consume the whole cluster. A LimitRange sets default and maximum requests and limits for individual containers, which lets quotas work when workloads omit resource settings. Neither object controls node-level scheduling, noisy neighbors inside a node, or the cluster-wide capacity that all tenants share. Confirm that quotas are set on every tenant namespace and that alerts fire before a quota blocks deployments.
NetworkPolicy for traffic isolation
A NetworkPolicy selects pods and allows or denies ingress and egress traffic between them, which is how most tenants are separated on the network. A policy has no effect unless the cluster's network plugin enforces it, and not every plugin does, so confirm enforcement in your chosen distribution before relying on it. Policies also do not control traffic leaving the cluster unless you write egress rules for it, and they do not replace encryption between services.
Pod Security Admission labels per namespace
Pod Security Admission reads labels on a namespace and applies one of three Pod Security Standards, Privileged, Baseline or Restricted, to pods created there. It limits settings such as host namespaces, privileged containers and host paths, which are common routes to node compromise. It does not evaluate RBAC, network paths or the images a pod runs, and it only applies to pods, so you must check that workload controllers and operators running in the namespace do not need exemptions that weaken the label.
Namespace tenancy or separate clusters: the trade-offs
This table compares three ways to share Kubernetes between teams: namespaces in one cluster, namespaces with stricter isolation controls, and separate clusters. Read each row for when the option fits and what it asks of the platform team to run. The main takeaway is that the operational cost rises as the isolation boundary moves outward, so choose the lightest boundary that meets your compliance scope and workload trust level.
| Option | When it fits | Operational cost |
|---|---|---|
| Namespace per team in one shared cluster | Teams with similar compliance scope that trust each other's workloads and where a shared control plane is acceptable. Namespaces, RBAC and resource quotas separate teams, but they do not stop a compromised pod from reaching the node or other tenants' traffic without additional controls. | Lowest control plane count and one upgrade cycle for everyone, which keeps policy consistent. Platform tooling stays modest. The risk is that a single API server, etcd or cluster-wide add-on outage affects every team, and noisy neighbors compete for shared nodes unless quotas are set carefully. |
| Namespace per team with stricter isolation controls | Teams with different sensitivity levels that can still share a control plane, such as a regulated workload beside internal tooling. Dedicated node pools with taints and tolerations, Pod Security Admission at Restricted, default-deny network policies and admission rules narrow the blast radius. | Still one control plane and one upgrade path, but node pools multiply, so idle capacity rises. Admission and network policy must be written, tested and kept consistent across namespaces, which adds platform tooling and review work. Ask who owns policy exceptions and how drift is detected. |
| One cluster per team or per trust level | Workloads with different compliance scopes, untrusted or multi-customer code, or teams that need independent Kubernetes versions and cluster-scoped permissions. A separate API server and etcd give the strongest boundary that Kubernetes itself offers. | Each cluster adds a control plane, its own upgrade and skew planning, its own backups and its own add-on stack, so coordination and labor scale with cluster count. Idle capacity grows because each cluster keeps headroom. Policy consistency depends on GitOps or templating, and the platform team must run fleet tooling for monitoring, certificates and access. |
How to build a shared-cluster tenancy model step by step
This sequence turns a shared Kubernetes cluster into a set of tenants with defined boundaries, each proven by a check before the next layer is added. The result is a written model that a platform team can operate, test and hand to auditors.
Define tenants and their trust levels
Start by listing every team, application group or customer that will share the cluster, and assign each one a trust level based on how much they trust each other and what data they handle. Decide which tenants may run privileged workloads, which may only run restricted ones, and which should not share the cluster at all. Record the result as a short table with an owner for each tenant. The step is done when the platform owner and each tenant lead have signed off on the table, and you can point to a tenant that should move to a separate cluster if the trust gap is too wide.
Decide namespace naming and ownership
Set a naming convention that encodes tenant, environment and purpose, and define who owns each namespace and who may request a new one. Keep cluster-scoped objects such as CustomResourceDefinitions, StorageClasses and admission configuration under platform ownership, not tenant ownership. Confirm the convention with a dry run: create the namespaces from a manifest, label them with tenant and owner, and query them back to check that every namespace resolves to exactly one owner. The step is complete when that query returns no unowned or ambiguous namespaces.
Create group-based RBAC bindings from the identity provider
Map identity provider groups to Roles and RoleBindings scoped to each tenant namespace, so access follows group membership rather than named users or shared kubeconfigs. Bind the groups to the least-privilege Role that matches their job, and use ClusterRoles only as reusable definitions bound inside a namespace. The identity integration itself is covered in the Kubernetes SSO and identity integration topic, so this step only depends on the group claims being present. Verify with impersonation: run kubectl auth can-i with --as and --as-group for a representative user from each tenant, and confirm that each group can act in its own namespaces and nowhere else.
Remove broad cluster-admin grants and unneeded service account tokens
Audit existing ClusterRoleBindings and find every grant of cluster-admin or wildcard permissions that does not belong to the platform team, then remove or narrow it. For workloads that never call the Kubernetes API, disable automatic mounting of the default service account token in the pod spec or on the service account, and give workloads that do need API access a dedicated service account with a minimal Role. Confirm the result by reviewing a full kubectl auth can-i matrix for each tenant service account across core resources and by listing the bindings that still reference cluster-admin, which should contain only platform identities.
Apply resource quotas and limit ranges per namespace
Create a ResourceQuota for each tenant namespace covering compute, object counts and storage, and a LimitRange that supplies default requests and limits so pods without explicit values still schedule predictably. Size the quotas from the capacity your tenants agreed to in step one and the nodes you actually have, and confirm the quota numbers with each tenant owner in writing. Verify by deploying a test workload that exceeds the quota and checking that the API server rejects it with a clear quota message, and by deploying a pod with no resource section and checking that the LimitRange defaults appear on it.
Apply Pod Security Admission labels per namespace
Enforce a Pod Security Standard on each tenant namespace using the built-in Pod Security Admission labels, choosing Restricted for tenants that run untrusted or internet-facing code, Baseline where existing workloads need more room, and Privileged only for platform namespaces that need it. Set enforce, audit and warn modes deliberately, starting with warn and audit on existing namespaces so you can see what would fail before enforcement. Verify by applying a deliberately non-compliant test pod to each namespace and confirming the admission decision matches the label you set.
Add default-deny network policies with explicit allows
In every tenant namespace, apply a default-deny policy for both ingress and egress, then add explicit allow rules for the traffic each application needs, such as ingress from the ingress controller, DNS egress to the cluster resolver, and approved service-to-service paths. Network policies only take effect if the cluster's network plugin enforces them, so confirm that with your networking vendor or distribution documentation before relying on them. Verify with connectivity tests from a pod in one tenant namespace toward a pod in another, which should fail, and toward each explicitly allowed path, which should succeed.
Record the tenancy model as a controlled document
Write the tenancy model as a single controlled document that lists tenants and trust levels, namespace conventions and owners, the RBAC map from groups to Roles, quota and LimitRange values, Pod Security Admission modes, and the network policy baseline with its allowed paths. Store the manifests that implement each item in version control, link them from the document, and name a reviewer and a review cadence. The step is done when a person outside the platform team can rebuild the access map from the document alone and the stored manifests match what is running in the cluster, which you check with a diff against the live objects.
How tenancy changes in single, separate and air-gapped clusters
In a single shared cluster, teams share one API server, one etcd datastore and one set of nodes. Tenancy comes from namespaces, Role and RoleBinding objects, ResourceQuota and NetworkPolicy. The platform team keeps control of cluster-scoped objects, such as ClusterRoleBindings and namespace creation, while application owners administer only their own namespaces.
- RBAC administration: Roles are scoped per namespace. A central team reviews every ClusterRoleBinding because those grant access across all namespaces.
- Where policy is enforced: Pod Security Admission applies one of the three Pod Security Standards through a label on each namespace. NetworkPolicy and ResourceQuota are enforced inside the cluster, but NetworkPolicy only works if the network plugin supports it.
- Upgrades and policy updates: One control plane upgrade affects every tenant at the same time. Test tenant workloads and admission behavior in staging before the single change window.
- Blast radius: A control plane fault, a change to a cluster-wide custom resource or a node pool problem reaches all tenants.
Confirm which namespace-scoped features and cluster-scoped add-ons your distribution ships, and confirm that your network plugin enforces NetworkPolicy before you rely on it for isolation between tenants.
Each team, environment or region gets its own cluster. A fleet-level source defines baseline roles, admission policy and namespace standards, and distributes them to every cluster. Local cluster administrators can still create bindings inside their own clusters, so configuration drift is the main risk in this model.
- RBAC administration: Role definitions live in one version-controlled source that clusters apply. Local teams manage group-to-role bindings that come from the identity provider.
- Where policy is enforced: Each cluster's API server and admission controllers enforce policy locally. A cluster that has not yet received a policy update is unprotected until it catches up.
- Upgrades and policy updates: Each cluster upgrades on its own schedule within the version skew rules, so the fleet may run more than one minor version for a period. Test every policy bundle against each version in use.
- Drift and audit evidence: Compare live state with the fleet source on a regular schedule and keep evidence for each cluster, since an auditor may ask about each boundary separately.
- Operating cost: Operational work grows with the number of clusters. The fleet tooling and its upkeep become recurring work for the platform team.
Ask who can change the fleet source, how drift is detected and reported, and how long a policy change takes to reach every cluster in the fleet.
Without internet access, the cluster cannot pull policy engine images, admission controller images or add-on images from public registries. Everything must come from a private registry that you populate through an approved transfer process. Kubeadm can list and pull the control plane images, and the --image-repository option points kubeadm init at your private registry. The tenancy model stays the same, but each artifact becomes an offline import that someone must verify.
- RBAC administration: Identity usually comes from an internal identity provider. Confirm that the cluster can reach that provider, and route binding changes through an approved internal workflow.
- Where policy is enforced: Pod Security Admission is built into the API server, so it does not need an external image. Any third-party admission webhook image must be mirrored and its version pinned.
- Policy and image updates: Each policy bundle, controller image and chart crosses the transfer process before it reaches tenants. Plan a regular update schedule that includes mirroring and verification time.
- Upgrades: Mirror the control plane images for each target minor version before the upgrade window opens. The version skew rules still apply.
- Network plugin: Confirm that the plugin's images and any policy controllers it depends on are in the mirror.
Confirm the full image list for your distribution, network plugin and admission components, including init containers and webhooks. Then test a complete pull from the private registry in an isolated staging network before go-live.
How to prove a tenant cannot reach another tenant
Isolation between tenants is only real once you have tried to break it and recorded what happened. Reading RoleBindings and NetworkPolicies gives you intent, but a test gives you behavior. Build a small, repeatable test suite that runs from the point of view of each tenant and checks four boundaries: the API, the network, the resource limits and the pod security settings. Keep the suite in version control next to the cluster configuration so the same checks can run in every environment. Start with an access matrix. For each tenant, use kubectl auth can-i with impersonation (the --as flag, with the tenant's user or service account) to test verbs such as get, list, create, delete and watch against resources in other namespaces and against cluster-scoped objects like Namespaces, Nodes, ClusterRoles and PersistentVolumes. Record every cell where the answer is yes and confirm each one is an intended grant. Include Secrets explicitly, because list and watch on Secrets in another namespace exposes credentials even when get is denied. Run the same matrix with a service account token from a workload, since automation identities are the ones most often over-granted.
The network test is a pod-level check. Deploy a probe pod in tenant A's namespace and attempt TCP connections to Services and pod IPs in tenant B's namespace on the ports those workloads expose. Run the same attempts in both directions and include DNS lookups for cross-namespace Service names. The expected result depends on your design: with a default-deny NetworkPolicy in place, connections should time out or be refused. Verify that the policy is enforced by your CNI plugin, because a NetworkPolicy object that the network layer ignores passes a manifest review and fails this test. Confirm your CNI's enforcement behavior in its own documentation before you rely on it.
The quota test confirms that over-limit creation is rejected rather than accepted and left pending. In a tenant namespace, create objects until the ResourceQuota ceiling is reached for pods, CPU, memory, services and persistent volume claims, then attempt one more of each. The API should return a forbidden error that names the exceeded quota. Also check that every workload type the tenant can create is covered by a quota or a LimitRange, since a pod created through a controller that sets no requests may bypass the sizing you expected. Ask your team to confirm how LimitRange defaults interact with quotas in your Kubernetes version, because the rules for objects without explicit requests are where gaps usually appear.
The Pod Security test confirms that privileged pods are refused in tenant namespaces. Attempt to create a pod with privileged: true, hostPath volumes, hostNetwork, hostPID and added Linux capabilities in each tenant namespace, and expect admission to refuse each one. Do the same for a namespace labeled to enforce the Baseline and Restricted levels of the Pod Security Standards. Use server-side dry run where possible so the test does not leave workloads behind. Keep the namespace labels and the admission results together as evidence, because a namespace that loses its enforce label during a change will still accept the same manifests. Deliberately test the failure modes that tend to erode isolation over time: a new RoleBinding added by another team that grants a tenant group cluster-wide read access, a ClusterRole edited to add a verb, a namespace created without its quota or network policy, and a service account automounting a token it does not need. Each failure should make at least one test go red. Store all results as dated evidence, and re-run the full suite after every Kubernetes upgrade and every change to RBAC, admission or network policy, since upgrades can change default behavior.
What drives Kubernetes multi-tenancy effort and cost
This table lists the factors that raise or lower the effort of sharing a Kubernetes cluster between teams, with what makes each one expensive and what keeps it manageable. Read each row as a question to answer before scoping: the more of these factors are high, the more the RBAC, quota and policy work grows. The main takeaway is that templated onboarding and policy as code usually matter more to long-term effort than the initial role design.
| Driver | How it raises effort | What keeps it down |
|---|---|---|
| Number of tenants and teams | Each team needs its own namespaces, role bindings, quotas and onboarding steps, so manual work scales with headcount and churn. | Generate namespaces, bindings and quotas from one template per tenant, and keep tenant records in version control. |
| Number of distinct trust levels | Teams with different trust levels need stronger isolation, such as Pod Security Standards at Restricted, network policies and separate node pools, which multiplies the controls to design and test. | Define a small set of tenant classes with fixed policy bundles instead of a custom configuration per team. |
| Number of clusters | Every cluster repeats RBAC, admission policy, add-on and upgrade work, and drift between clusters becomes a source of audit findings. | Manage all clusters from one Git repository with the same policy set, and count clusters as a tenancy decision, not a convenience. |
| Identity provider integration complexity | Group claims from the identity provider must map to RBAC roles, and group naming, nested groups or missing claims create access errors that take time to trace. | Agree group naming rules with the identity team first, and map groups to a short list of cluster roles that tenants do not edit. |
| Workloads that need privileges or host access | Privileged pods, host networking, hostPath volumes and node-level tooling need exceptions, extra review and sometimes a separate namespace or cluster, which adds design work for each case. | Keep privileged workloads in a dedicated namespace or node pool with a written exception record, and default all other tenants to Baseline or Restricted. |
| Network plugin capabilities | Tenant isolation through NetworkPolicy depends on what the chosen network plugin enforces, and a plugin without policy support pushes isolation work to other layers or other clusters. | Confirm the plugin's policy enforcement and logging support with the vendor or project before design, and test default-deny behavior in staging. |
| Existing manifests with cluster-scoped objects | Cluster-scoped resources such as ClusterRoles, CRDs, admission configurations and StorageClasses in application manifests conflict with tenant boundaries and must be moved or reviewed one by one. | Inventory cluster-scoped objects in existing manifests during migration planning, and move platform-owned objects to a separate platform repository. |
| Compliance scope | Auditors may ask for evidence of access reviews, least-privilege RBAC, audit logs and policy enforcement per tenant, and each evidence source must be produced and kept current. | Agree the evidence list with the assessor early, and generate access and policy reports from the same tooling used to deploy tenants. |
| Onboarding process for new tenants | If onboarding needs tickets, manual kubectl steps and person-specific knowledge, every new team adds lead time and the chance of inconsistent setup. | Use a self-service request that runs the same templated pipeline, with approval recorded as a Git change and tested by automated policy checks. |
Running tenancy after go-live: reviews, upgrades and handover
Tenancy controls degrade quietly after go-live unless the platform team runs them on a schedule. The first recurring task is a periodic access review of RoleBindings and ClusterRoleBindings, both namespaced and cluster-wide. Export the bindings, join each subject to the identity provider group that should own it, and remove bindings whose group no longer exists or whose owner has left. Pay particular attention to bindings that reference the built-in cluster-admin ClusterRole and to bindings to the default service account, which are easy to create by accident and rarely reviewed. Record the reviewer, the date and the removals so the review itself becomes audit evidence.
Between reviews, alert on new cluster-admin grants. Audit logging of create and update events on ClusterRoleBindings and RoleBindings that reference cluster-admin should page the platform on-call, not wait for the next quarterly review. Pair this with a check that no tenant namespace has gained a binding that widens access beyond the role catalog. Confirm with your distribution and logging stack which audit policy levels are available and how long events are retained, because both decide whether a grant can be traced back to a change request.
Quota and network coverage need their own routine. Report resource quota usage per tenant namespace, comparing requests and limits against the quota each tenant was granted, so that a team approaching its ceiling is raised before its deployments fail. For network isolation, check every newly onboarded namespace for a default-deny NetworkPolicy and confirm that the cluster's network plugin enforces policies at all; the Kubernetes docs only define the API, so test enforcement with a short connectivity probe rather than assuming it. Namespaces created outside the onboarding template are the usual gap, so compare the live namespace list against the onboarding records each week.
Every Kubernetes upgrade needs the isolation test suite run again, before and after the change. The version skew policy sets the order of control plane and node upgrades, but it says nothing about whether your RBAC rules, admission policies or NetworkPolicies still behave the same, so the tests must prove it. In the same cycle, review deprecated API usage in tenant manifests, using the deprecation warnings returned by the API server and a scan of the manifests in the Git repositories that tenants deploy from. Ask each tenant to fix their own manifests before the old API is removed, and track open items as exceptions.
The handover package turns these routines into something the owning team can run without the original builders. It should contain the tenancy model document, the namespace onboarding template, the RBAC role catalog, the isolation test scripts and the list of exceptions, with a named owner and a review date for each exception. Ask the implementation partner to confirm in writing which items are delivered, in what format, and whether the test scripts run against your cluster without DeployOpen tooling. An exception with no owner is a finding waiting to happen, so make the exception list the first document the platform team reviews each quarter.
What do buyers ask about Kubernetes multi-tenancy before hiring help?
What drives the cost of a Kubernetes multi-tenancy project?
The cost is driven mainly by how many tenants you host, how much you trust each of them, how many identity sources must be connected, and how many exceptions your current setup already carries. A cluster shared by a few internal teams that trust each other is a small design job. A cluster shared with external customers, or with teams that must be isolated from one another for regulatory reasons, needs stronger boundaries, more policy, more testing and more evidence. Each exception to the standard model, such as a workload that needs host access or a team that needs cluster-wide permissions, adds design and review work. Ask any provider to price these items separately, and ask which parts are one-time (design, build, testing) and which recur (policy changes, access reviews, upgrades).
Can an internal team set up Kubernetes multi-tenancy without outside help?
Yes, if the team already runs Kubernetes in production and has someone who understands RBAC, admission policy and network policy well enough to test them. Many teams do this successfully for internal tenants. The work becomes harder when tenants are untrusted, when identity must be federated from an external provider, or when auditors will ask for evidence. Outside help is most useful for an independent design review, for testing that the isolation actually holds, and for producing the documentation and control evidence that assessors request. Whichever path you take, assign a named owner for tenant onboarding and access reviews, because those tasks continue after the initial build.
Are Kubernetes namespaces enough to isolate untrusted tenants?
No. Namespaces are a logical grouping that RBAC, resource quotas, network policies and Pod Security Admission can apply to, but they do not create a hard security boundary on their own. All tenants share the same API server, the same nodes, the same kernel and the same cluster-scoped resources such as CustomResourceDefinitions and StorageClasses. A workload that escapes its container can reach the node, and a permissive network policy can expose services across namespaces. For tenants you do not trust, most teams combine namespaces with restricted Pod Security levels, network policies, dedicated node pools, and sometimes separate clusters. Confirm the exact boundary you need with your security team before design starts.
What do we need to provide before a Kubernetes multi-tenancy quote?
A useful quote starts with four inputs from your side. First, a tenant list that names each team or customer, its data sensitivity and whether it is trusted. Second, the identity groups that will map to roles, with the identity provider they come from. Third, a workload inventory that shows what each tenant runs, including any privileged, host-networked or stateful workloads. Fourth, the compliance scope: which frameworks, controls and systems the assessment covers. Also share the Kubernetes distribution, version and where the clusters run, because these affect which features are available. Missing inputs usually become exceptions later, and exceptions are what extend the schedule and the cost.
How is a Kubernetes multi-tenancy engagement quoted?
DeployOpen does not publish a price list. Most engagements are fixed-scope, which means the scope, deliverables and timeline are written and agreed before work begins, and the quote follows from that written scope. Ask for the scope to list the tenants and trust levels covered, the identity integration included, the policies and network controls to be built, the testing to be performed, the documentation delivered and the handover steps. Ask which items are one-time and which would move to a retainer for ongoing access reviews, policy updates and upgrade support. If a proposal cannot tie each line to a deliverable, ask for it to be rewritten before you compare it with other quotes.
How long does Kubernetes multi-tenancy work usually take?
The duration depends on the same drivers as cost: the number of tenants, their trust levels, the identity sources to connect, and the exceptions that need design review. Pilot tenants on an existing cluster can often be onboarded in a shorter cycle than a multi-cluster design with external customers. Time is also lost when compliance evidence requirements are unclear late in the project. Ask any provider for a timeline built from the written scope, with milestones for design sign-off, build, testing in staging and cutover. DeployOpen states timelines only in the written scope for each engagement, so the figure you receive should reflect your environment, not a generic estimate.
What is the difference between a shared cluster and separate clusters for tenants?
A shared cluster lowers infrastructure and operations overhead, but every tenant depends on the same control plane, upgrade schedule and cluster-scoped configuration. Separate clusters give each tenant a stronger boundary and independent upgrades, at the cost of more clusters to patch, monitor and back up. Many organizations choose a hybrid model: shared clusters for trusted internal teams and dedicated clusters for sensitive or external tenants. The right choice depends on your trust model, your regulatory scope and how many people you have to run the platform. Make this decision first, because it sets the cost and effort of every later step.
How DeployOpen scopes, builds and hands over tenancy work
DeployOpen plans, builds and documents Kubernetes RBAC and multi-tenancy inside your own clusters, cloud accounts or data centers. Each engagement starts from a written scope that sets out which teams share which clusters, which boundaries are enforced and what your team will own afterwards.
How we scope
- Inventory the teams, workloads and trust levels that will share each cluster, and mark where separate clusters are the safer boundary.
- Agree the namespace model, role mapping and quota approach in writing before any configuration changes begin.
- Confirm which identity source supplies groups, and which service and automation identities need roles, in the written scope.
How we build
- Create namespaces, Roles, ClusterRoles and bindings with least-privilege permissions, applied through version-controlled manifests.
- Configure ResourceQuotas, LimitRanges and network policies for each tenant, then test that isolation holds with deliberate cross-namespace access attempts.
- Apply Pod Security Standards per namespace and check that restricted Secrets access and audit logging behave as designed.
How we hand over
- Deliver a tenancy runbook covering onboarding, offboarding, quota changes and role review steps for your platform team.
- Provide test evidence, including RBAC permission checks and isolation test results, that your auditors or security reviewers can inspect.
- Walk your engineers through the manifests and rehearse one tenant onboarding so they can repeat it without DeployOpen.
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer, separate from the fixed-scope build.
- Re-check RBAC and isolation rules when Kubernetes minor versions change, since your supported releases move on a regular cycle.
- Ask any provider to confirm in writing which parts of role review, quota changes and incident response are included in a retainer.
