The Kubernetes multi-tenancy guidance says that, by default, pods in a cluster can communicate with one another. It also recommends starting with a default-deny pod communication policy when strict network isolation between tenants is required. This is a useful reminder for a buyer: a namespace label or a clean diagram is a proposed boundary, while an observed decision tells you whether the boundary works.
Quick answer. A Kubernetes multi-tenant isolation assessment should verify control-plane authorization, workload admission, service-account credentials and pod-to-pod reachability separately. Give the tester synthetic tenants and an approved positive and negative case for each boundary, then require the policy object, observed decision and redacted evidence in the report. The matrix below is Stingrai's buyer-facing synthesis of Kubernetes documentation, not a Kubernetes conformance program.
The question appears whenever separate product teams, customers, environments or regulated workloads share a cluster. Different teams may own namespaces, but the Kubernetes API server, node estate and some controllers remain shared infrastructure. An operator may intend “Team A cannot reach Team B” while the actual restrictions cover only network packets, only API calls, or only new pod creation. This article turns those separate claims into reportable tests for a security review or a penetration test statement of work.
The method assumes authorization from the cluster owner. It uses disposable identities, test namespaces, synthetic secrets and clearly bounded network probes. It does not ask a tester to break into the underlying cloud provider, touch other customers' infrastructure or interrupt production services. A production cluster can still be assessed, but the owner should choose test fixtures that make the evidence safe to collect.
One phrase, several different boundaries
“Tenant isolation” is too broad to be a single pass or fail result. Kubernetes distinguishes control-plane isolation from data-plane isolation. A namespace can organize namespaced resources and policy, but it does not automatically turn shared nodes, shared controllers, credentials or network paths into a private cluster. The buyer must state which boundaries it expects to hold.
At the API boundary, Kubernetes RBAC determines which resource verbs an identity may use and at what scope. At the workload boundary, Pod Security Admission can reject a pod that violates the selected standard, while a pod created under a permissive policy may have privileges the owner did not intend. At the credential boundary, a pod can receive a token for its assigned ServiceAccount. At the network boundary, NetworkPolicy can restrict connections only when the chosen networking solution supports and enforces it. None of these controls should be inferred from the presence of another.
The RBAC documentation illustrates a particularly important distinction. The built-in edit role can access Secrets and run Pods as any ServiceAccount in its namespace. A buyer who believes edit means “ordinary developer access” needs to examine the actual trust they are granting within that namespace. Kubernetes also warns that users who can create or edit workloads may be able to raise their privileges inside the namespace through the workloads they run (Authorization). The test plan should measure the assigned role against the intended tenant boundary, not trust a familiar role name.
Figure 1: Four different decisions need four different evidence types. Sources: Kubernetes multi-tenancy, RBAC, Pod Security Admission and NetworkPolicy. The evidence sequence is Stingrai's synthesis.
The original multi-tenant isolation matrix
Each row below starts with an owner's intended rule. “Allowed” and “denied” are safe test outcomes for synthetic fixtures, not instructions to attempt access to live data. A test should stop when a boundary behaves unexpectedly and record what happened for the operator. The matrix is an editorial procurement tool; no Kubernetes document declares these rows to be a mandatory pentest checklist.
Boundary | Positive and negative case | What to capture | Primary anchor |
|---|---|---|---|
Namespace-scoped API access | Tenant A can read its own approved object; its identity cannot read the equivalent Tenant B object | RBAC binding, namespace, subject, API decision | |
Cluster-wide privilege | A designated platform operator can use a named cluster resource; a tenant identity is denied | ClusterRoleBinding, subject and decision | |
Secret access | Approved workload can read its synthetic secret; another tenant's identity or workload cannot | Secret owner, role scope and observed denial | |
Workload creation | Approved tenant workload can be created; tenant cannot create a workload that gains an unapproved service identity | Role, requested ServiceAccount and admission result | |
ServiceAccount token mount | A workload that needs API access receives the intended identity; a workload that does not need it has no mounted token | Pod spec, effective ServiceAccount and token-mount state | |
Pod Security enforcement | A compliant disposable pod is admitted; a deliberately nonconforming test pod is rejected where | Namespace labels, policy version, admission response | |
Admission observation | A test violation in | Policy mode, audit event or warning, actual creation result | |
East-west network path | Approved Tenant A service call succeeds; an unapproved A-to-B pod connection is denied | NetworkPolicy, network plugin, source and destination, result | |
Name resolution | A tenant workload can resolve approved service names while the default-deny policy still blocks unrelated peers | DNS exception policy and connection outcomes | |
Egress | Approved outbound destination succeeds; an unapproved synthetic destination is denied under the owner policy | Egress policy, destination class and result | |
Shared node or controller | The documented shared component is visible only to the roles intended to administer it | Component owner, role scope and denied tenant action | |
Retest after policy change | A fixed boundary rejects the same unauthorized synthetic case while preserving its allowed case | Before and after policy revision and decisions | Stingrai test-design criterion |
The most useful column is the one that asks for what actually happened. A RoleBinding screenshot is not a denial result. A NetworkPolicy resource is not proof that packets were filtered. A Pod Security label in audit mode is not proof of enforcement. The report should align the intended restriction with the observed control-plane or data-plane decision and should name every missing test.
RBAC evidence: scope the identity, not the label
An assessor needs the subject behind each request: user, group or ServiceAccount. It also needs the binding that grants permission, the namespace or cluster scope, and the resource verb being tested. “The developer role was read only” is inadequate if a different ClusterRoleBinding grants a broader action. RBAC evaluation is the combined result of applicable grants, so a report should record the effective access path.
Ask for an ordinary tenant identity and a separate platform-operator identity. The allowed case confirms that the test setup works. The denied case asks whether Tenant A can act on an equivalent synthetic object in Tenant B's namespace. Repeat the pattern for a cluster-scoped resource only if tenants should be blocked from it. A provider should not need to read sensitive production Secrets to prove this boundary; a disposable Secret with a harmless marker is enough.
Built-in roles deserve explicit treatment. Kubernetes' RBAC page explains that edit can access Secrets and run Pods as any ServiceAccount in the namespace, while view omits Secrets because Secret access can expose ServiceAccount credentials. An organization can still choose to grant edit, but it should understand that namespace members with that role may share the power of service accounts in the namespace. The acceptance question is whether that consequence matches the tenancy model.
Workload creation is another RBAC-adjacent path. Kubernetes' authorization guidance cautions that users who can create or edit Pods can gain access through workload behavior. A defensive test can ask for the policy and a controlled attempt to run a disposable workload under a higher-trust service identity. The report records admission or denial and stops. It does not need to harvest credentials or chain to production systems to show the control decision.
Admission evidence: enforcement, audit and warning differ
Pod Security Admission defines enforce, audit and warn as separate modes. enforce rejects a pod that violates the configured standard. audit allows the pod but adds an audit annotation. warn allows the pod while presenting a warning. These are materially different outcomes. A dashboard that says a namespace is “restricted” without its mode leaves the buyer unable to know whether nonconforming work is stopped or merely observed.
The fixture can be a harmless, short-lived pod specification selected with the operator. The allowed case is a conforming workload. The denied case is a nonconforming specification appropriate to the selected Pod Security Standard. The evidence should include the namespace labels, the standard level and version, the admission response, and whether an audit or warning event was created. Do not use a live service pod or a configuration that could disrupt other workloads.
Namespace coverage matters. The Kubernetes best-practices page says namespaces without any Pod Security configuration should be treated as significant gaps for review. That statement does not mean every namespace must use the most restrictive standard. System components and special workloads may need different levels. It means an unlabeled namespace should have a conscious owner and a documented reason, rather than disappearing from the test because nobody listed it.
An exception also needs a stated boundary. The owner should name which namespace or workload requires elevated permissions, who can deploy there and how that exception is monitored. The assessor should then check that an ordinary tenant cannot route its own workload through the exception. Again, the evidence is an allowed path for the approved operator and a denied path for the tenant, not a blanket assertion that privileged workloads are unsafe.
Service-account evidence: what a pod can carry
Kubernetes service-account documentation says Pods receive credentials for their assigned ServiceAccount by default. It also documents automountServiceAccountToken: false for a Pod that should not receive those credentials automatically. The decision to mount a token belongs to the workload owner. The test should show which ServiceAccount a workload runs as, whether a token is present when needed, and whether an unrelated workload is deliberately left without one.
Do not infer that a short-lived projected token alone supplies isolation. It changes token handling, while RBAC and workload assignment determine what the token can do. An assessor should therefore pair token-mount evidence with an authorization decision against a synthetic resource. A token that rotates may still carry excessive permissions; a workload with no token may still reach another tenant over the network. These are separate questions.
Service accounts used by shared controllers require special attention. A controller may legitimately operate across namespaces, but a tenant should not be able to cause it to act outside the tenant's approved scope. The buyer should supply controller ownership and the expected delegation rule. The assessor should test with benign synthetic objects and report whether the shared component honored that rule. If the controller's implementation cannot be safely exercised, record the limitation and ask for configuration or code review evidence instead.
Network evidence: a resource is not a packet decision
NetworkPolicy is an API object, but the Kubernetes documentation says it has no effect without a networking solution that supports the policy. Therefore, the report needs the cluster network plugin and at least one observed allowed and denied connection. A policy manifest by itself proves only that the API accepted the object.
For strict tenant separation, Kubernetes recommends starting with default-deny pod communication and adding needed allowances such as DNS. A buyer should write down the intended service graph: which tenant may call which service, which namespaces host shared infrastructure, and which egress destinations are necessary. The test then uses simple synthetic services on each side of the boundary. It checks an intended connection first, then a disallowed one, while recording source, destination and policy selection.
NetworkPolicy does not answer API authorization, and API authorization does not prove network filtering. A workload can have no permission to list Tenant B's Pods while still being able to connect to Tenant B's service if the network permits it. A workload can have the opposite combination. The matrix deliberately requires evidence for both control planes.
Be careful with transient results. A failed request may be caused by an unavailable test service, DNS failure or an unready endpoint rather than a policy denial. The positive control demonstrates reachability where intended. Repeat a disputed result with the operator and preserve timestamps. The final report should label network observations as observed, not extrapolate a single test into a guarantee about every protocol or every node.
Set the rules of engagement for a shared cluster
The scope should list cluster name and version, managed-service boundary, network plugin, test namespaces, identities, approved target services, maintenance window and a stop contact. It should also name the cluster components that are expressly outside the engagement, such as provider-operated control-plane internals in a managed service. A customer can authorize its workloads and configurations; it cannot authorize testing of a provider's other tenants.
Use no real customer records and no production Secret contents as proof. Synthetic resources work for API and Secret checks. A short-lived test deployment works for admission and network checks. Agree on a cleanup owner and verify that all test objects are removed after the engagement. The final evidence can retain identifiers and redacted logs without keeping active credentials.
Ask the tester to describe limitations at the same resolution as results. “Network tests excluded” is too broad if RBAC and admission were tested. “Namespace B egress could not be checked because a supporting test service was unavailable” is actionable. This precision helps procurement compare proposals and lets engineering plan a targeted retest instead of commissioning a second whole-cluster assessment.
Preserve an evidence packet that can be repeated
For every tenant pair, record the identities and namespaces used, the expected decision, the observed API or network result and the policy objects that governed it. Preserve the cluster version and the network plugin identified at test time. A finding about NetworkPolicy enforcement is difficult to interpret later if the report never names the component that was meant to implement it. The Kubernetes NetworkPolicy documentation explicitly makes that dependency part of the control's behavior.
Record both a denied cross-tenant action and an allowed own-tenant action. The allowed control tells an engineer that a proposed remediation has not merely disabled an entire application or prevented all Pods from starting. It also helps separate a permission boundary from a broken test fixture. Use disposable Pods and synthetic Secrets with names that make cleanup straightforward; record the fixture removal in the handoff. A security review should leave the shared cluster in the owner's expected operating state.
Treat an untested boundary as a limitation, not a pass. A network path may be excluded because the provider did not approve the test, or an admission check may require a disposable namespace the buyer did not provide. State the missing fixture, the effect on the conclusion and who can authorize a later test. That precision is part of the value of the matrix: it keeps a broad “tenant isolation validated” claim from resting on a narrow RBAC check.
How to buy and use the result
Attach the matrix to the request for proposal and ask bidders to mark each row included, excluded or dependent on a fixture. Require the performer to identify which policy configuration it will inspect, which safe negative cases it will execute and what redacted output it will supply. Ask whether the scope covers both cluster API decisions and pod network behavior. The broad cloud and Kubernetes scoping guide helps define the overall engagement; this matrix is the narrower tenant-isolation acceptance test.
A useful executive summary says which tenant boundary was tested, where it held, where it failed and what remained untested. Findings should name the owner of the relevant RBAC binding, Pod Security setting, service-account assignment or network policy. Retesting should repeat the original denied case and one allowed control after the change. A fix that blocks all traffic or all workload creation may close a narrow finding while breaking the system; the allowed control shows that the intended service path still works.
The report can support a SOC 2, ISO 27001 or other compliance program with concrete evidence of access-control and segmentation testing. Its value is reproducible proof for engineers and a legible scope for buyers.
Where Stingrai fits
Stingrai is a proud CREST-accredited penetration testing service provider whose cloud testing scope includes Kubernetes RBAC, network policies, secrets handling and control-plane exposure. Human-led testers can apply this matrix to a customer-owned cluster using named synthetic tenants, work within the provider's testing rules and report the actual boundary decisions with remediation guidance. The same scope can be commissioned as a one-time engagement or revisited in a continuous program when tenants, roles and policies change.
Snipe is Stingrai's autonomous agent for web applications and their APIs. The Kubernetes identity, admission and network checks here belong to human-led cloud testing. If an application running in the cluster also needs authorization testing, scope that application separately and identify which findings come from the application rather than from cluster tenancy. Send a cluster diagram and test-tenant plan through Get a Quote.
How to cite this matrix
Citation: Arafat Afzalzada, “Kubernetes Multi-Tenant Isolation Test Matrix: RBAC, Pods, Tokens and NetworkPolicy,” Stingrai, 16 October 2026. The allow and deny cases are an original buyer-facing synthesis. The linked Kubernetes project documentation remains the authority for each underlying control's behavior.
Frequently Asked Questions
What should a Kubernetes multi-tenant penetration test prove?
It should prove, with approved synthetic identities and workloads, that one tenant can use its own permitted resources while access to another tenant's resources is denied at the intended API, admission, credential and network boundaries.
Does a Kubernetes namespace isolate tenant network traffic by itself?
No. Kubernetes says Pods can communicate by default. Network isolation requires a suitable policy and a networking solution that enforces it, followed by observed allowed and denied connection tests.
Is a NetworkPolicy manifest enough evidence of isolation?
No. Kubernetes documents that a NetworkPolicy has no effect when the network plugin does not support it. The report should identify the plugin and show a connection result from the approved source to the approved and denied destinations.
What is the difference between Pod Security enforce, audit and warn?
Enforce rejects a violating Pod. Audit records a violation while allowing it. Warn gives a user-facing warning while allowing it. The report should identify the configured mode and what happened to the disposable test workload.
Why inspect the built-in edit role?
Kubernetes documents that edit can access Secrets and run Pods as any ServiceAccount in its namespace. A buyer should decide whether that power fits the tenant model and verify which identities actually receive the role.
Should every workload mount a ServiceAccount token?
No. Kubernetes provides credentials for an assigned ServiceAccount by default, and documents how to turn off automatic token mounting for a Pod that does not need API access. The assessment should check the owner-approved decision for each representative workload.
Can this test be run without reading real Secrets or customer data?
Yes. Synthetic Secrets, disposable Pods and test services can demonstrate allowed and denied decisions. The customer should approve the fixtures, boundaries and cleanup plan before testing.
Does Snipe test Kubernetes RBAC and network policy?
No. Snipe is scoped to web applications and their APIs. Stingrai's human-led cloud penetration testing can assess Kubernetes RBAC, workload identity, Pod Security Admission and network isolation under an authorized cluster scope.
Related reading
References
Kubernetes. Multi-tenancy. Accessed 16 October 2026. https://kubernetes.io/docs/concepts/security/multi-tenancy/. Control-plane and data-plane considerations, including default pod connectivity.
Kubernetes. Using RBAC Authorization. Accessed 16 October 2026. https://kubernetes.io/docs/reference/access-authn-authz/rbac/. Built-in roles and resource authorization.
Kubernetes. Authorization. Accessed 16 October 2026. https://kubernetes.io/docs/reference/access-authn-authz/authorization/. Workload creation and privilege consequences.
Kubernetes. Pod Security Admission. Accessed 16 October 2026. https://kubernetes.io/docs/concepts/security/pod-security-admission/. Enforce, audit and warn modes.
Kubernetes. Enforcing Pod Security Standards. Accessed 16 October 2026. https://kubernetes.io/docs/setup/best-practices/enforcing-pod-security-standards/. Namespace configuration guidance.
Kubernetes. Service Accounts. Accessed 16 October 2026. https://kubernetes.io/docs/concepts/security/service-accounts/. Assigned identities and automatic token mounting.
Kubernetes. Network Policies. Accessed 16 October 2026. https://kubernetes.io/docs/concepts/services-networking/network-policies/. Plugin enforcement dependency and policy semantics.
Stingrai. Cloud Penetration Testing. Accessed 16 October 2026. https://www.stingrai.io/services/cloud-penetration-testing. Published Kubernetes testing scope.
Talk to Stingrai
Share your cluster version, test namespaces and expected tenant boundaries through Get a Quote, or book a free discovery call to agree on safe proof and retest criteria.
