VMware Tanzu User Management API Guide

Auth method: OAuth 2.0 (via CSP / Workspace ONE Access token exchange); Kubernetes service account tokens for TAP cluster-level operations

Setup steps

1. Log in to VMware Cloud Services Portal (CSP) and obtain an API token from My Account > API Tokens.
2. Exchange the CSP API token for a short-lived access token: POST https://console.cloud.vmware.com/csp/gateway/am/api/auth/api-tokens/authorize with the api_token parameter.
3. Pass the returned access_token as a Bearer token in the Authorization header for all TMC API calls.
4. For Tanzu Application Platform (TAP) cluster operations, configure Pinniped with your OIDC/LDAP IdP; users authenticate via kubeconfig generated by the Pinniped concierge.
5. Assign TMC roles (organization.admin, cluster.admin, etc.) or TAP Kubernetes RBAC ClusterRoleBindings to users/groups as appropriate.

Required scopes

List organization members (CSP)

• Method: GET
• URL: https://console.cloud.vmware.com/csp/gateway/am/api/orgs/{orgId}/users
• Watch out for: Requires csp:org_admin scope. Returns CSP org membership, not TMC-specific role bindings.

Request example

GET /csp/gateway/am/api/orgs/{orgId}/users
Authorization: Bearer <access_token>

Response example

{
  "results": [
    {"userId":"uuid","email":"user@example.com","role":"org_member","status":"ACTIVE"}
  ],
  "pagination": {"next":"..."}
}

Invite user to organization (CSP)

• Method: POST
• URL: https://console.cloud.vmware.com/csp/gateway/am/api/orgs/{orgId}/invitations
• Watch out for: User must accept the invitation email before they become ACTIVE. Invitation expiry is not publicly documented.

Request example

POST /csp/gateway/am/api/orgs/{orgId}/invitations
{
  "usernames": ["user@example.com"],
  "orgRoleName": "org_member"
}

Response example

{
  "invitationLink": "https://console.cloud.vmware.com/csp/...",
  "invitedUsers": [{"email":"user@example.com","status":"INVITED"}]
}

Remove user from organization (CSP)

• Method: DELETE
• URL: https://console.cloud.vmware.com/csp/gateway/am/api/orgs/{orgId}/users/{userId}
• Watch out for: Removing a user from the CSP org does not automatically remove TMC role bindings; those must be deleted separately.

Request example

DELETE /csp/gateway/am/api/orgs/{orgId}/users/{userId}
Authorization: Bearer <access_token>

Response example

HTTP 204 No Content

List TMC IAM role bindings

• Method: GET
• URL: https://<tmc-hostname>.tmc.cloud.vmware.com/v1alpha1/iam/rolebindings
• Watch out for: Scope the query with searchScope parameters (orgId, clusterGroupName, clusterName) to avoid overly broad results.

Request example

GET /v1alpha1/iam/rolebindings?searchScope.orgId=<orgId>
Authorization: Bearer <access_token>

Response example

{
  "roleBindings": [
    {"name":"rb-1","role":"organization.admin","subjects":[{"name":"user@example.com","kind":"USER"}]}
  ]
}

Create TMC IAM role binding

• Method: POST
• URL: https://<tmc-hostname>.tmc.cloud.vmware.com/v1alpha1/iam/rolebindings
• Watch out for: User must already be a member of the CSP org. Role binding creation does not send notifications.

Request example

POST /v1alpha1/iam/rolebindings
{
  "roleBinding": {
    "role": "cluster.admin",
    "subjects": [{"name":"user@example.com","kind":"USER"}],
    "scope": {"cluster":{"name":"my-cluster"}}
  }
}

Response example

{
  "roleBinding": {
    "name":"rb-abc123",
    "role":"cluster.admin",
    "subjects":[{"name":"user@example.com","kind":"USER"}]
  }
}

Delete TMC IAM role binding

• Method: DELETE
• URL: https://<tmc-hostname>.tmc.cloud.vmware.com/v1alpha1/iam/rolebindings/{name}
• Watch out for: Role bindings are immutable once created (scope and role cannot be changed); delete and recreate to modify.

Request example

DELETE /v1alpha1/iam/rolebindings/rb-abc123
Authorization: Bearer <access_token>

Response example

HTTP 200 OK
{"roleBinding":{"name":"rb-abc123"}}

Get SCIM configuration (TMC IdP integration)

• Method: GET
• URL: https://<tmc-hostname>.tmc.cloud.vmware.com/v1alpha1/account/iamproviders
• Watch out for: SCIM provisioning in TMC is configured via the IdP (Okta, Entra ID) pointing to a TMC-generated SCIM endpoint. The endpoint URL and bearer token are generated in the TMC console under Administration > Identity Providers.

Request example

GET /v1alpha1/account/iamproviders
Authorization: Bearer <access_token>

Response example

{
  "iamProviders": [
    {"name":"okta-scim","type":"SCIM","status":"ACTIVE"}
  ]
}

List TAP users (Kubernetes RBAC via kubectl/API server)

• Method: GET
• URL: https://<tap-api-server>/apis/rbac.authorization.k8s.io/v1/clusterrolebindings
• Watch out for: TAP user management is Kubernetes-native RBAC; there is no dedicated TAP user REST API. Users are managed as Kubernetes subjects in ClusterRoleBindings/RoleBindings.

Request example

GET /apis/rbac.authorization.k8s.io/v1/clusterrolebindings
Authorization: Bearer <kubeconfig-token>

Response example

{
  "items": [
    {"metadata":{"name":"tap-developer-rb"},"subjects":[{"kind":"User","name":"dev@example.com"}],"roleRef":{"name":"app-editor"}}
  ]
}

• Rate limits: VMware/Broadcom does not publicly document specific numeric rate limits for the TMC or TAP APIs in official documentation as of the research date.

• Rate-limit headers: Unknown

• Retry-After header: Unknown

• Rate-limit notes: No explicit rate-limit tiers, headers, or Retry-After behavior documented publicly. Consult Broadcom support for enterprise SLA details.

• Pagination method: token

• Default page size: 20

• Max page size: Not documented

• Pagination pointer: page_token / page_size (TMC API uses next_page_token in response for cursor-based pagination)

• Webhooks available: No

• Webhook notes: VMware Tanzu Mission Control and Tanzu Application Platform do not expose a documented outbound webhook system for user lifecycle events (user added, removed, role changed) in official documentation.

• Alternative event strategy: Use TMC API polling or integrate with your IdP's (Okta/Entra ID) outbound webhook/event system to detect user changes, then call TMC/CSP APIs reactively.

• SCIM available: Yes

• SCIM version: 2.0

• Plan required: Enterprise (bundled with VMware Cloud Foundation or vSphere Foundation; requires SSO/IdP federation to be configured first)

• Endpoint: https://.tmc.cloud.vmware.com/scim/v2 (endpoint URL and bearer token generated per-IdP-connection in TMC Administration > Identity Providers console)

• Supported operations: Create User (POST /Users), Update User (PUT /Users/{id}), Deactivate/Delete User (PATCH /Users/{id} active=false or DELETE /Users/{id}), List Users (GET /Users), Create Group (POST /Groups), Update Group membership (PATCH /Groups/{id}), List Groups (GET /Groups)

Limitations:

• SCIM endpoint URL is dynamically generated per IdP connection in the TMC console; it is not a static, universal endpoint.
• SSO (OIDC/SAML via Workspace ONE Access or direct IdP federation) must be configured before SCIM provisioning can be enabled.
• SCIM provisioning provisions users into the TMC/CSP organization; Kubernetes-level RBAC (TAP ClusterRoleBindings) must still be managed separately.
• Supported IdPs for SCIM are Okta and Microsoft Entra ID per official documentation; Google Workspace and OneLogin are not listed as supported.
• Exact SCIM attribute mapping (e.g., custom attributes) may be limited; consult TMC IdP integration guides for supported schema extensions.

Three integration patterns are well-supported by the available API surface, each with distinct caveats.

Provisioning a developer into TMC with cluster access is a multi-step, partially async flow: invite via CSP (POST /orgs/{orgId}/invitations), poll until status is ACTIVE, then create a TMC role binding (POST /v1alpha1/iam/rolebindings).

The role binding creation will fail or produce a dangling binding if the user has not yet accepted the invitation - automate polling with a hard timeout.

SCIM-based deprovisioning via Okta or Microsoft Entra ID handles TMC/CSP org membership removal cleanly, but it does not cascade to Kubernetes RBAC bindings on TAP clusters.

A separate kubectl or Kubernetes API call to delete ClusterRoleBindings is required on every affected TAP cluster after SCIM deactivation.

Supported SCIM IdPs are Okta and Microsoft Entra ID per official documentation;

Google Workspace and OneLogin are not listed.

Bulk group assignment via SCIM group push is supported: create the group in the IdP, push it to the TMC SCIM endpoint, then create a TMC role binding with subject kind=GROUP.

Group names in TMC role bindings must exactly match the SCIM-provisioned group name - case sensitivity and special characters cause silent binding mismatches.

Provision a new developer into Tanzu Mission Control with cluster-level access

1. Exchange CSP API token for access token: POST https://console.cloud.vmware.com/csp/gateway/am/api/auth/api-tokens/authorize
2. Invite user to CSP org: POST https://console.cloud.vmware.com/csp/gateway/am/api/orgs/{orgId}/invitations with role org_member.
3. Wait for user to accept invitation (status transitions to ACTIVE); poll GET /orgs/{orgId}/users to confirm.
4. Create TMC role binding: POST https://.tmc.cloud.vmware.com/v1alpha1/iam/rolebindings with role cluster.admin scoped to the target cluster.
5. Verify: GET /v1alpha1/iam/rolebindings?searchScope.clusterName= and confirm the user subject appears.

Watch out for: Step 3 requires human action (email acceptance); automate polling with a timeout. Do not create the TMC role binding before the user is ACTIVE or it may fail.

Deprovision a user from Tanzu Mission Control via SCIM (Okta)

1. In Okta, unassign the user from the Tanzu Mission Control SCIM application.
2. Okta sends PATCH /Users/{scimUserId} with active=false (or DELETE) to the TMC SCIM endpoint.
3. TMC deactivates the user's org membership.
4. Verify via TMC API: GET /v1alpha1/iam/rolebindings to confirm role bindings are removed, and GET /orgs/{orgId}/users to confirm status is REMOVED.
5. If TAP cluster access was granted via Kubernetes RBAC, manually delete the relevant ClusterRoleBinding on each TAP cluster using kubectl or the Kubernetes API.

Watch out for: SCIM deprovisioning handles TMC/CSP org membership but does NOT automatically remove Kubernetes RBAC bindings on TAP clusters. A separate cleanup step is required for TAP.

Bulk-assign a group to a TMC cluster group using SCIM group push

1. In your IdP (Okta/Entra ID), create a group (e.g., tanzu-cluster-admins) and assign users to it.
2. Configure group push in the IdP's TMC SCIM app to sync the group to TMC.
3. IdP sends POST /Groups to the TMC SCIM endpoint, creating the group and its members in TMC.
4. In TMC, create a role binding for the group: POST /v1alpha1/iam/rolebindings with subject kind=GROUP, name=tanzu-cluster-admins, scoped to the target cluster group.
5. Future IdP group membership changes (add/remove members) are automatically synced via SCIM PATCH /Groups/{id}.

Watch out for: Group names in TMC role bindings must exactly match the SCIM-provisioned group name. Case sensitivity and special characters in group names can cause binding mismatches.

The primary integration trap is assuming CSP org membership and TMC role bindings are a single system. Deleting a user from the CSP org (DELETE /orgs/{orgId}/users/{userId}) does not cascade-delete their TMC role bindings - those must be removed separately via DELETE /v1alpha1/iam/rolebindings/{name}.

A deprovisioned user with stale TMC bindings retains a defined access posture in the identity graph even after org removal.

TMC role binding names are system-generated and immutable. To change a user's role or scope, the existing binding must be deleted and a new one created - there is no PATCH or PUT operation for role modification. This makes role change workflows more complex to implement idempotently.

Rate limits for the TMC and CSP APIs are not publicly documented. No rate-limit headers or Retry-After behavior is specified in official sources - consult Broadcom support for enterprise SLA details before building high-frequency polling loops. Pagination uses cursor-based next_page_token with a default page size of 20;

max page size is undocumented. Finally, post-Broadcom acquisition, some API documentation has migrated from docs.vmware.com to developer.broadcom.com - older endpoint references in internal tooling may resolve to stale or redirected URLs.