Summary and recommendation
VMware Tanzu user management can be run manually, but complexity usually increases with role models, licensing gates, and offboarding dependencies. This guide gives the exact mechanics and where automation has the biggest impact.
VMware Tanzu Application Platform (TAP) delegates all user access to Kubernetes RBAC - there is no local user directory.
Every app team member must exist in a connected OIDC or LDAP identity provider before any access can be granted.
TAP ships four default namespace-scoped roles: app-editor, app-viewer, app-operator, and service-operator.
Bindings are applied per namespace using the tanzu CLI or kubectl.
A user needing access to multiple namespaces must be bound individually in each one - there is no org-wide role assignment for workload access.
The Tanzu Developer Portal (TAP GUI) uses a separate auth configuration and does not inherit namespace RBAC bindings automatically.
Quick facts
| Admin console path | Tanzu Developer Portal (formerly TAP GUI) > Settings; cluster-level RBAC managed via tanzu CLI or kubectl |
| Admin console URL | Official docs |
| SCIM available | Yes |
| SCIM tier required | Enterprise |
| SSO prerequisite | Yes |
User types and roles
| Role | Permissions | Cannot do | Plan required | Seat cost | Watch out for |
|---|---|---|---|---|---|
| app-editor | Create, edit, and delete workloads in a namespace; view supply chain, deliverable, and related resources | Cannot manage cluster-level resources, install TAP packages, or modify RBAC bindings | Role is namespace-scoped; must be bound per namespace. Does not grant access to the Tanzu Developer Portal catalog by default. | ||
| app-viewer | Read-only access to workloads, supply chains, deliverables, and related resources within bound namespaces | Cannot create, edit, or delete any workloads or resources | Namespace-scoped; must be explicitly bound per namespace. | ||
| app-operator | Edit and manage supply chains, delivery, and related operator-level resources; can update workload configuration | Cannot install or upgrade TAP packages; cannot manage cluster-level RBAC | Namespace-scoped. Distinct from platform operator role. | ||
| service-operator | Manage service instances and service bindings within namespaces | Cannot manage workloads or supply chains directly | Namespace-scoped. Requires Services Toolkit component to be installed. | ||
| cluster-admin (Kubernetes) | Full cluster-level access including TAP package installation, namespace creation, and RBAC management | This is a standard Kubernetes ClusterRole, not a TAP-specific role. TAP installation requires cluster-admin. Should be restricted to platform operators only. |
Permission model
- Model type: role-based
- Description: VMware Tanzu Application Platform uses Kubernetes RBAC as its underlying permission model. TAP ships a set of default ClusterRoles (app-editor, app-viewer, app-operator, service-operator) that are bound to users or groups at the namespace level using the tanzu CLI or kubectl. Authentication is delegated to an external OIDC or LDAP identity provider configured at install time.
- Custom roles: Yes
- Custom roles plan: Not documented
- Granularity: Namespace-scoped role bindings; roles map to Kubernetes RBAC verbs on specific TAP CRD resource types. Custom Kubernetes ClusterRoles or Roles can be created and bound independently of TAP default roles.
How to add users
- Ensure an OIDC or LDAP identity provider is configured in the TAP values file under the 'shared.activateAppToolkitFeatures' or 'tap_gui.app_config.auth' sections and TAP is reconciled.
- Identify the target namespace where the user needs access.
- Run: tanzu rbac binding add -u
-r -n (e.g., tanzu rbac binding add -u user@example.com -r app-editor -n my-namespace) - Alternatively, apply a Kubernetes RoleBinding manifest using kubectl: kubectl create rolebinding
--clusterrole= --user= -n - For group-based binding: tanzu rbac binding add -g
-r -n - Verify the binding: tanzu rbac binding get -n
Required fields: User email or username (as it appears in the identity provider token), Target namespace, Role name (app-editor, app-viewer, app-operator, or service-operator)
Watch out for:
- Users must already exist in the configured identity provider; TAP does not have a local user directory.
- Role bindings are namespace-scoped by default; a user needing access to multiple namespaces must be bound in each namespace separately.
- The tanzu RBAC plugin must be installed separately: tanzu plugin install rbac.
- Tanzu Developer Portal (TAP GUI) authentication is configured separately from workload namespace RBAC and may require additional catalog/plugin permissions.
- If using Pinniped for authentication federation, the Pinniped supervisor and concierge must be correctly configured before user bindings take effect.
| Bulk option | Availability | Notes |
|---|---|---|
| CSV import | No | Not documented |
| Domain whitelisting | No | Automatic domain-based user add |
| IdP provisioning | Yes | Enterprise (bundled with VMware Cloud Foundation or vSphere Foundation; SCIM provisioning requires Enterprise tier) |
How to remove or deactivate users
- Can delete users: Unknown
- Delete/deactivate behavior: TAP does not maintain a local user store; users are authenticated via an external identity provider (OIDC/LDAP). Removing a user's access requires deleting their RoleBinding(s) in each namespace and disabling or removing the user in the identity provider. Official docs do not describe a 'deactivate' concept distinct from removing bindings.
- Remove the user from the identity provider (Okta, Azure AD/Entra, LDAP, etc.) to prevent authentication.
- Delete the namespace-level RoleBinding(s) for the user: tanzu rbac binding delete -u
-r -n - Alternatively: kubectl delete rolebinding
-n - Repeat for each namespace where the user has bindings.
- If the user has Tanzu Developer Portal access, remove them from any configured auth provider groups that grant portal access.
| Data impact | Behavior |
|---|---|
| Owned records | Workloads and resources created by the user remain in the namespace after bindings are removed; Kubernetes resources are not automatically deleted when a user loses access. |
| Shared content | Supply chain runs, deliverables, and pipeline results created by the user persist in the cluster. |
| Integrations | Service bindings and external integrations created by the user remain active until explicitly deleted. |
| License freed | TAP licensing is core-based (per VCF/VVF subscription), not per-seat; removing a user does not free a license seat. |
Watch out for:
- Removing bindings does not terminate active user sessions; session expiry depends on the OIDC token TTL configured in the identity provider.
- If the user is a member of a group that has a RoleBinding, removing the individual user binding is insufficient; the user must also be removed from the group in the IdP.
- Core-based licensing means there is no per-user license reclamation process.
License and seat management
| Seat type | Includes | Cost |
|---|---|---|
| VMware Cloud Foundation (VCF) core license | Includes Tanzu Application Platform, vSphere, vSAN, NSX, and other VCF components as a bundle | Custom pricing; approximately $350/core/year as of post-Broadcom acquisition pricing (minimum 72 cores required) |
| vSphere Foundation (VVF) core license | Includes a subset of Tanzu capabilities (Tanzu Kubernetes Grid) bundled with vSphere and vSAN | Custom pricing; sold per core with minimum commitment |
- Where to check usage: Broadcom Support Portal (support.broadcom.com) > My Dashboard > Licenses; or VMware Customer Connect portal for legacy entitlements
- How to identify unused seats: License consumption is tracked at the core/CPU level via the Broadcom licensing portal, not at the individual user level. Unused Tanzu features within a VCF entitlement do not reduce license cost.
- Billing notes: Under Broadcom ownership (post-2023), Tanzu is no longer sold as a standalone product. All Tanzu components are bundled within VCF or VVF subscriptions. Minimum 72-core purchase required. Subscription-only model; perpetual licenses are no longer available. Existing customers reported price increases of 150–1000%+ at renewal.
The cost of manual management
Because bindings are namespace-scoped, every app a team owns in a separate namespace requires its own binding operation. At scale, this creates compounding administrative overhead: onboarding one developer across ten namespaces means ten discrete tanzu rbac binding add commands or kubectl RoleBinding manifests.
Removing a user requires deleting bindings in every namespace they were granted, then disabling the account in the identity provider. Active OIDC sessions persist until token TTL expires - there is no forced session revocation documented in official sources. Tanzu Developer Portal access must be revoked separately through the IdP group configuration.
License consumption is tracked at the CPU core level via the Broadcom portal, not per user. There is no per-seat reclamation process; unused Tanzu features within a VCF entitlement do not reduce cost.
What IT admins are saying
Community evidence is not specific enough to quote or summarize yet for this app.
The decision
TAP's RBAC model is well-suited to platform engineering teams that already operate Kubernetes at scale and have a mature IdP integration. The namespace-scoped binding model maps cleanly to multi-tenant cluster topologies where every app team owns discrete namespaces.
It is a poor fit for organizations expecting a SaaS-style admin console with point-and-click user management. There is no fixed admin URL - the Tanzu Developer Portal host is deployment-specific. Teams without existing Kubernetes RBAC tooling or IdP federation experience will face a steep operational ramp.
The Broadcom pricing model is the dominant decision factor for most organizations today. Tanzu cannot be purchased standalone; it requires a VCF or VVF subscription with a 72-core minimum.
Any evaluation must account for the full bundle cost, not Tanzu in isolation.
Bottom line
VMware Tanzu Application Platform gives platform engineering teams a Kubernetes-native RBAC model that integrates cleanly with enterprise IdPs, but it offloads nearly all user lifecycle management to the operator.
Every app namespace requires explicit, individual role bindings - onboarding and offboarding are manual, multi-step processes with no built-in automation or session revocation.
Layered on top of that operational complexity is a pricing structure that has materially increased costs for most existing customers post-Broadcom acquisition, with no standalone purchase path and a 72-core minimum commitment.
Teams evaluating Tanzu today should treat the VCF bundle cost and the RBAC operational overhead as first-order concerns, not afterthoughts.
Automate VMware Tanzu workflows without one-off scripts
Stitchflow builds and maintains end-to-end IT automation across your SaaS stack, including apps without APIs. Built for exactly how your company works, with human approvals where they matter.
