Wednesday, February 15, 2023
HomeCloud ComputingVMware Cloud Director Service Accounts

VMware Cloud Director Service Accounts


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

As a recap take a look at the API Tokens characteristic 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 person accounts:

With out service accounts, automation instruments require the creation of devoted dummy person 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 by way of 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 obligatory, revoke entry to the Service Accounts.

Service accounts could be created both in system or tenant context, nevertheless, solely the system directors by default can create them. In case an Group administrator/person wants the power to create Service Accounts for his or her group, then the next rights could 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 person 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
  • World roles
  • Rights bundles

Functions accessing VMware Cloud Director by utilizing a service account shouldn’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 Possibility:

  • Navigate to Administration > Supplier Entry Management (or “Entry Management” in tenant portals) > Service Accounts.
  • To create a Service Account, the administrator gives the next:
    • A UUID because the Software program ID (UI gives 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 Title
    • VCD Position
    • Moreover, the next metadata concerning the account being created: Software program Model –  model of automation’s selecting included for informational functions
    • Shopper URI – optionally available URL that can be informational and may function contact data
  • On the subsequent display screen, outline quotas for the Service Account.

API Possibility:

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

Headers:
Settle for: utility/json;model=37.0
Content material-Sort: utility/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: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 should be communicated to the device that intends to make use of the service account. Shopper-id is a part of the OAuth specs, upon which their authentication is predicated.

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 could be assured to solely be with the device that should use it. To perform this, VCD implements the System 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 gives a number of items of data 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 ought to 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 ought to 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 utility, the gadget code from step 3 should be offered by the appliance/gadget to the administrator who makes use of it to lookup the service account, critiques 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 – Lively 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 by way of 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 (by way of the usual POST/oauth/supplier/token?grant_type=refresh_token&refresh_token=<API_token>).

In contrast to the common person API tokens, API tokens granted to service accounts rotate on each use. Every time an entry token is retrieved by way of the refresh token name, a brand new refresh token is offered 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 Lively Stage.

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

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 person who creates objects.
  2. Service accounts are principals, akin to person accounts. Thus, they’ll (if granted adequate privileges), create and personal property like vApps, VMS, catalogs, templates, media, and many others.
  3. Service accounts can allow automation to take care of worth add property as themselves.
  4. Duties initiated by service accounts are correctly attributed and occasions will determine them as actors.
  5. Like every principals, property could also be shared with or Service Account.
  6. The administrator can handle Service Accounts to vary the account function, 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 Lively stage). Upon revocation, the Service Account Stage modifications 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 could be deleted ensure that any objects beforehand created by the Service Account should be manually deleted or transferred to a different person.

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


RELATED ARTICLES

Most Popular