Monday, December 5, 2022
HomeCloud ComputingVMware Cloud Director Service Accounts

VMware Cloud Director Service Accounts

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 high of API Token infrastructure which adopts OAuth requirements. Service Accounts have entry through API solely and no UI entry.

As a recap have 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 Function Friday – API Tokens).

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 making certain 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 essential, revoke entry to the Service Accounts.

Service accounts might 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 might be granted to permit this:

  • View Service Accounts
  • Handle Service Accounts


As a result of using service accounts is geared 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 through the use of a service account, functions have solely view rights for the next assets:

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

Purposes accessing VMware Cloud Director through the use of a service account don’t have the next rights:

  • Token: Handle
  • Token: Handle All

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 methods)
    • Service Account Title
    • VCD Position
    • Moreover, the next metadata concerning the account being created: Software program Model –  model of automation’s selecting included for informational functions
    • Consumer URI – non-compulsory URL that can be informational and may function contact info
  • On the subsequent display screen, outline quotas for the Service Account.

API Choice:

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

Settle for: utility/json;model=37.0
Content material-Kind: utility/json
Authorization: Bearer

“client_name”: “AVS”,
“software_id”: “874df0da-aa5e-401d-aa78-07fcbd784ec5”,
“software_version”: “1.0”,
“client_uri”: “”,
“scope”: “urn:vcloud:function: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 have to be communicated to the instrument that intends to make use of the service account. Consumer-id is a part of the OAuth specs, upon which their authentication relies.

Step 3 – Requested Stage

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

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

As per the usual, entry grant circulate is initiated by the service account. Because the 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 utility)

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

  • The response offers a number of items of knowledge right here that guarantee correct coordination between an administrator and the service account.
    • device_code: The exterior utility/gadget 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 consists of 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 quick use.

Administrator steps:

For the administrator to grant entry to the exterior utility, the gadget code from step 3 have to be supplied by the appliance/gadget to the administrator who makes use of it to lookup the service account, evaluations 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 excellent 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 utility 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 consumer is obligated to discard the outdated 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 info.

Further 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 some other consumer who creates objects.
  2. Service accounts are principals, akin to consumer accounts. Thus, they’ll (if granted adequate 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 establish them as actors.
  5. Like every principals, belongings could also be shared with or Service Account.
  6. The administrator can handle Service Accounts to alter the account function, software program ID, software program model, consumer URI, or quota restrictions.
  7. The administrator can revoke beforehand granted entry (just for Service Account have to 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 have to be redone.
  8. The administrator can delete the Service Account. Earlier than a Service Account might be deleted guarantee that any objects beforehand created by the Service Account have to be manually deleted or transferred to a different consumer.

Due to Ankit Shah & Tomas Fojta for his or her help and collaboration on this effort.



Please enter your comment!
Please enter your name here

Most Popular

Recent Comments