TL;DR · Key Takeaways
- Access control is two layers: vSphere Namespace permissions govern who can manage clusters, Kubernetes RBAC governs what users do inside them.
- Authenticate with kubectl using the kubeconfig, or with the VCF CLI using a revocable token. Token auth is the stronger default for shared clusters; a leaked static kubeconfig is forever.
- Pod Security Admission replaces PodSecurityPolicy. Default namespaces to restricted or baseline and make privileged an explicit, scoped exception.
- Real isolation is RBAC + PSA + network policy + registry control. Any three of the four leaves a hole, most commonly missing network policy on a shared cluster.
Security on VKS is where the vSphere world and the Kubernetes world meet, and the seam is exactly where people get confused. Who can create a cluster is a vSphere question. Who can deploy into it is a Kubernetes question. Mix those up and you either lock developers out or hand them far too much. This part draws the line clearly and then covers the controls that actually contain a workload, because RBAC alone does not.
Two layers of access control
The first layer is the vSphere Namespace. The permissions an administrator sets there decide which DevOps users can manage the lifecycle of VKS clusters in that namespace, create, scale, upgrade, delete. The second layer is Kubernetes RBAC inside each workload cluster, which decides what an authenticated user can do once in: which namespaces, which verbs, which resources. They work together. The namespace permission gets you the right to provision and own a cluster; cluster RBAC is how you grant your developers scoped access to it. Say it as a slogan and it sticks: namespace permissions decide who runs the cluster; RBAC decides who uses it.
Authentication and Pod Security Admission
Once a cluster exists you download its kubeconfig and connect with kubectl, which remains fully supported in VCF 9, and there is a graphical Local Consumption Interface (LCI) for browsing and operating clusters. For shared clusters the stronger pattern is token-based access through the VCF CLI: you authenticate with a valid token, the token can be revoked, and periodic re-authentication is enforced. That revocability is the security advantage, a leaked static kubeconfig is forever; a token is not. Where VCF Automation deploys a shared cluster, a JWT authenticator can be registered so VCF Automation identities are used directly.
The old PodSecurityPolicy is gone from upstream Kubernetes, and VKS uses Pod Security Admission (PSA) with the pod security standards instead. PSA enforces a baseline at the namespace level, restricted, baseline or privileged, so a workload asking for host access, privileged containers or dangerous capabilities is rejected unless its namespace is explicitly allowed to run it. Default namespaces to restricted or baseline and grant privileged only where a specific workload genuinely needs it, with a ClusterRoleBinding that scopes that privilege deliberately rather than enabling it everywhere.
Real isolation takes four controls, not one
RBAC controls actions, not blast radius. Genuine tenant isolation is the sum of four controls, and leaving any one out is where breaches hide:
| Control | Stops | If you skip it |
|---|---|---|
| RBAC | Unauthorized actions on objects | Users do things they shouldn’t |
| Pod Security Admission | Privileged / host-level pods | A pod escapes its boundary |
| Network policy (Antrea) | Cross-namespace pod traffic | Pods talk freely despite tidy RBAC |
| Registry control | Arbitrary / untrusted images | Supply-chain risk walks in |
How authentication actually flows
It helps to trace what happens when a user runs a command against a cluster, because the answer determines how you revoke access when someone leaves. With a plain downloaded kubeconfig, the cluster trusts a credential embedded in that file, and that credential is effectively permanent until the cluster is rebuilt or the certificate rotated. With the token-based path through the VCF CLI, the user authenticates against an identity source, receives a short-lived token, and presents that token to the cluster, which validates it. The difference is everything for offboarding: revoke the identity or the token and access is gone immediately, whereas a leaked static kubeconfig keeps working until you notice and rebuild. Where VCF Automation deploys a shared cluster, a JWT authenticator can be registered so the cluster trusts VCF Automation identities directly, which is the cleanest model for shared platforms because identity lives in one place.
The design rule that follows is simple: static kubeconfigs are for automation accounts and break-glass, not for humans. Humans authenticate through the token path so their access is tied to a revocable identity, and you keep a short, audited list of who holds a static credential and why. The first time you have to offboard someone in a hurry, you will be glad their access was a token and not a file three people copied to their laptops.
Network policy patterns that hold up
Network policy is the control most often missing, so it is worth being concrete about what good looks like. The pattern that holds up under audit is default-deny per namespace: drop all ingress and egress, then explicitly allow only the flows each workload needs. A frontend may talk to its backend, the backend to its database, and nothing else moves. With Antrea you also get cluster-wide policies and tiering, so a platform team can set guardrails that individual namespace owners cannot override, which is what lets you delegate namespaces to teams without surrendering the security boundary. The mistake to avoid is the allow-all-then-tighten-later approach, because later never comes and you ship a flat cluster where any compromised pod can reach everything.
Start strict. A default-deny baseline that you open deliberately is a posture you can defend; an open cluster you intend to lock down someday is a finding waiting to happen. Because Antrea integrates with NSX, those policies are also visible to the network team in the tooling they already use, so segmentation is not a Kubernetes-only secret that the rest of security cannot see.
The supply chain: registries, scanning, signing
Most Kubernetes compromises do not break the platform; they walk in through a container image. Controlling the supply chain means three things on VKS. First, constrain which registries clusters may pull from, so a workload cannot quietly pull latest from an arbitrary public registry; point everything at a private registry you curate. Second, scan those images for known vulnerabilities before they are allowed to run, and make a failing scan block the deployment rather than file a ticket nobody reads. Third, verify image provenance, signed images and an admission policy that rejects unsigned ones, so what runs is what you built and approved, not something substituted along the way.
These controls are enforced with admission policy in the cluster, which is the same mechanism behind Pod Security Admission, so it is a layer you are already running. The point is that RBAC, Pod Security and network policy protect the cluster from its users, while registry control, scanning and signing protect it from its workloads. A serious platform needs both halves; teams that harden access and ignore the supply chain have locked the front door and left the loading dock open.
Authentication flow: token versus kubeconfig
The choice between a downloaded kubeconfig and token-based access is really a choice about how you offboard someone, and the flows make the difference concrete. A static kubeconfig embeds a credential the cluster trusts effectively forever; revoking it means rebuilding or rotating. A token is issued by an identity source, short-lived, and validated on each use, so revoking the identity kills access immediately.
A rule you can hand to auditors
Humans authenticate through the token path so their access is tied to a revocable identity; static kubeconfigs are reserved for automation accounts and break-glass, on a short audited list with a reason attached. Where VCF Automation deploys a shared cluster, a JWT authenticator lets the cluster trust VCF Automation identities directly, so identity lives in one place rather than scattered across downloaded files.
In practice
The day you have to offboard a contractor in a hurry is the day this decision pays off. If they authenticated with tokens, you disable the identity and you are done. If they had a downloaded kubeconfig that two colleagues also copied, you are rotating credentials or rebuilding clusters under time pressure. Make the token path the default before you need it, not after.
The four-control isolation model, visualised
Real tenant isolation is not one control but four working together, and picturing them as concentric layers shows why dropping any one leaves a gap. RBAC governs who can act, Pod Security governs how privileged a workload can be, network policy governs what can talk to what, and registry control governs what is allowed to run at all. Miss one and the others do not cover for it.
The ring people forget
The control most often missing is network policy. Teams set up careful RBAC so users cannot see each other’s objects, declare the cluster multi-tenant, and never notice that the pods can still reach each other across namespaces because nothing stops them. Default-deny network policy is what makes the isolation real rather than cosmetic, and it is the ring that turns “looks isolated” into “is isolated.”
Worked example
A penetration test on a shared cluster found that a low-privilege pod in one team’s namespace could open a connection straight to another team’s database pod. RBAC was immaculate, nobody could see anyone else’s objects, but there was no network policy, so the pod network was flat. Adding a default-deny baseline and explicit allows closed the finding. The lesson stuck: RBAC hides objects, network policy stops traffic, and isolation needs both.
Audit logging as your evidence trail
The control nobody thinks about until an auditor or an incident asks for it is the Kubernetes audit log, the record of who did what to the API and when. Without it, a question like “who deleted that deployment” or “when did this permission change” has no answer, and in a regulated environment that gap is a finding in itself. Enable audit logging on clusters that carry anything sensitive, ship the audit events to the same centralised platform as your other logs so they survive node churn and cannot be tampered with locally, and tune the policy so it captures the writes and the sensitive reads without drowning in routine chatter. The audit trail is the difference between “we believe access is controlled” and “we can show exactly who touched this,” and the second is the one that holds up under scrutiny. It is cheap to turn on early and impossible to reconstruct after the fact.
What I’d Do
I keep the two tiers crisp: namespace permissions for who can run clusters, RBAC for who can use them, and I never blur them. For shared clusters I prefer revocable token auth over handing out static kubeconfigs, because revocation is the difference between rotating a credential and rebuilding a cluster. I default every namespace to a restricted or baseline pod security standard and treat privileged as a scoped exception with a name attached. And I never call a tenant “isolated” until all four controls are in place, with default-deny network policy doing the work RBAC cannot. Decide between separate clusters per tenant (strongest, more overhead) and shared clusters with disciplined namespace isolation based on how much you trust your tenants. On your busiest shared cluster right now: is there a default-deny network policy, or just RBAC that hides objects while the pods chat freely?
References
- Broadcom TechDocs: Configuring Identity and Access for VKS Clusters
- Broadcom TechDocs: Pod Security for VKS Clusters
- Broadcom Knowledge: How to Configure Kubernetes RBAC for a VKS Cluster
About The Author
DrJha