Wednesday, April 22, 2026
HomeCloud ComputingVMware Cloud Director Service Accounts

VMware Cloud Director Service Accounts

[ad_1]

VMware Cloud Director (VCD) v10.4 introduces Service Accounts, as a substitute for consumer accounts, which permits standalone entry for automation and third-party functions/instruments (e.g. plugins) to VMware Cloud Director. This function is constructed on prime of API Token infrastructure which adopts OAuth requirements. Service Accounts have entry through API solely and no UI entry.

As a recap take a look at the API Tokens function which was beforehand launched for customers in VCD v10.3.1. (Blogged at Cloud Director API Tokens and defined at ).

Benefits of Service Accounts over consumer accounts:

With out service accounts, automation instruments require the creation of devoted dummy consumer accounts both as VCD native customers or setting them up in IDPs (LDAP).

  1. System or tenant administrator(s) have higher management principals accessing VCD through automation by guaranteeing credential possession is unique to that principal. Thus, except service accounts themselves disclose their credentials, they can’t be impersonated by anybody else auditing in VCD identifies service accounts as principals.
  2. Service Accounts make the most of the beforehand launched API token infrastructure to authenticate with VCD, with enhanced safety measures that rotate their API token upon every use. There’s higher management for the directors to confirm, grant and if obligatory, revoke entry to the Service Accounts.

Service accounts may be created both in system or tenant context, nevertheless, solely the system directors by default can create them. In case an Group administrator/consumer wants the power to create Service Accounts for his or her group, then the next rights may be granted to permit this:

  • View Service Accounts
  • Handle Service Accounts

Limitations

As a result of using service accounts is aimed toward third-party functions, Service Accounts have some limitations. These limitations are for good and higher management over who does what.

When utilizing service accounts, functions can not carry out sure duties:

  • Carry out consumer administration duties
  • Create API tokens
  • Handle different service accounts

When accessing VMware Cloud Director by utilizing a service account, functions have solely view rights for the next assets:

  • Person
  • Group
  • Roles
  • International roles
  • Rights bundles

Functions accessing VMware Cloud Director by utilizing a service account would not have the next rights:

  • Token: Handle
  • Token: Handle All

Learn how to Create Service Account:

Step1 – Preliminary Setup:

Directors can create Service Accounts both from the UI (Person Interface) or utilizing the APIs

UI Choice:

  • Navigate to Administration > Supplier Entry Management (or “Entry Management” in tenant portals) > Service Accounts.
  • To create a Service Account, the administrator offers the next:
    • A UUID because the Software program ID (UI offers a handy choice to rapidly create one, however it’s inspired that one is entered in order that it may be managed by the automation programs)
    • Service Account Identify
    • VCD Function
    • Moreover, the next metadata in regards to the account being created: Software program Model –  model of automation’s selecting included for informational functions
    • Consumer URI – non-obligatory URL that can be informational and may function contact data
  • On the subsequent display, outline quotas for the Service Account.

API Choice:

POST https://host_name/oauth/supplier/register

Headers:
Settle for: software/json;model=37.0
Content material-Sort: software/json
Authorization: Bearer

Physique:
{
“client_name”: “AVS”,
“software_id”: “874df0da-aa5e-401d-aa78-07fcbd784ec5”,
“software_version”: “1.0”,
“client_uri”: “vcdavs.com”,
“scope”: “urn:vcloud:position:Systempercent20Administrator”
}

Step 2 – Created Stage

At this stage, the Service Account is within the Created Stage (The account is within the preliminary stage after creation). 

VCD has assigned a client-id to the account which should be communicated to the software that intends to make use of the service account. Consumer-id is a part of the OAuth specs, upon which their authentication is predicated.

Step 3 – Requested Stage

On this step, the exterior software is given entry to the service account.

As famous above, the API token possession is managed such that the custodianship of that token may be assured to solely be with the software that should use it. To perform this, VCD implements the Gadget Authorization code movement as described in RFC 8268.

As per the usual, entry grant movement is initiated by the service account. For the reason that service account and administrator should work in tandem to perform this, let’s break down the steps for each:

Service Account Steps (carried out by the exterior software)

POST /oauth/supplier/device_authorization name utilizing the given client_id from step 2 to provoke machine authorization

  • The response offers a number of items of data right here that guarantee correct coordination between an administrator and the service account.
    • device_code: The exterior software/machine retains this and can use it to ballot VCD for the API token
    • user_code: One-time code to be communicated again to the administrator for approval
    • The response additionally contains expires_in (a timeout in seconds) which is the window of time throughout which the entry enablement course of must be accomplished.

At this stage, the Service Account is within the Requested Stage and is ready for the administrator’s approval.

Step 4 – Granted Stage

At this stage, the identical name will return the API token (refresh_token) for entry to VCD. This must be handled as a secret by the service account. An access_token can be included within the response for fast use.

Administrator steps:

For the administrator to grant entry to the exterior software, the machine code from step 3 should be supplied by the appliance/machine to the administrator who makes use of it to lookup the service account, opinions the main points and both Grant or Denies the request.

At this stage, the Service Account is within the Granted Stage (An administrator granted an impressive request and is awaiting the service account polling and fetching of the API token).

Step 5 – Energetic Stage

On the finish of step 3, the exterior software began to ballot VCD for API token. As soon as the administrator granted entry (Step 4) the appliance lastly receives the API token through the identical API name POST /oauth/supplier/device_authorization.

VCD transmits each access_token (for use instantly for the present session) and an API token for use for the subsequent session (through the usual POST/oauth/supplier/token?grant_type=refresh_token&refresh_token=<API_token>).

Not like the common consumer API tokens, API tokens granted to service accounts rotate on each use. Every time an entry token is retrieved through the refresh token name, a brand new refresh token is supplied within the reply for the subsequent session. The shopper is obligated to discard the previous API Token and retailer the brand new token for the subsequent use. The unused service account API tokens by no means expire except you revoke the service account. This course of follows RFC 6749 part 6.

The Service Account strikes into the Energetic Stage.

The under demonstration makes use of the API token to fetch the group data.

Extra Notes

  1. Any object created utilizing the Service Accounts API Token will present the initiator because the Service Account and the Proprietor because the Service Account, the identical as another consumer who creates objects.
  2. Service accounts are principals, similar to consumer accounts. Thus, they will (if granted ample privileges), create and personal belongings like vApps, VMS, catalogs, templates, media, and many others.
  3. Service accounts can allow automation to take care of worth add belongings as themselves.
  4. Duties initiated by service accounts are correctly attributed and occasions will determine them as actors.
  5. Like all principals, belongings could also be shared with or Service Account.
  6. The administrator can handle Service Accounts to vary the account position, software program ID, software program model, shopper URI, or quota restrictions.
  7. The administrator can revoke beforehand granted entry (just for Service Account should be in Granted or Energetic stage). Upon revocation, the Service Account Stage adjustments to Created and the entry grant course of described in Step 4 should be redone.
  8. The administrator can delete the Service Account. Earlier than a Service Account may be deleted ensure that any objects beforehand created by the Service Account should be manually deleted or transferred to a different consumer.

Because of Ankit Shah & Tomas Fojta for his or her assist and collaboration on this effort.


[ad_2]

RELATED ARTICLES

LEAVE A REPLY

Please enter your comment!
Please enter your name here

Most Popular

Recent Comments