VMware Cloud Director (VCD) v10.4 introduces Service Accounts, as a substitute for consumer accounts, which permits standalone entry for automation and third-party purposes/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 by way of 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 Characteristic 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).
- System or tenant administrator(s) have higher management principals accessing VCD by way of 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.
- 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 will 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 will be granted to permit this:
- View Service Accounts
- Handle Service Accounts
Limitations
As a result of using service accounts is geared toward third-party purposes, Service Accounts have some limitations. These limitations are for good and higher management over who does what.
When utilizing service accounts, purposes can’t 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, purposes have solely view rights for the next sources:
- Person
- Group
- Roles
- World roles
- Rights bundles
Purposes accessing VMware Cloud Director through the use of a service account do not need the next rights:
- Token: Handle
- Token: Handle All
Tips on 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 gives the next:
- A UUID because the Software program ID (UI gives a handy choice to shortly create one, however it’s inspired that one is entered in order that it may be managed by the automation techniques)
- Service Account Identify
- VCD Function
- Moreover, the next metadata concerning the account being created: Software program Model – model of automation’s selecting included for informational functions
- Shopper URI – elective URL that can be informational and may function contact info
- On the following display, outline quotas for the Service Account.
API Choice:
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 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 will be assured to solely be with the device that should use it. To perform this, VCD implements the System Authorization code move as described in RFC 8268.
As per the usual, entry grant move 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 system authorization
- The response gives a number of items of knowledge right here that guarantee correct coordination between an administrator and the service account.
- device_code: The exterior utility/system 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 needs 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 needs to be handled as a secret by the service account. An access_token can be included within the response for rapid use.
Administrator steps:
For the administrator to grant entry to the exterior utility, the system code from step 3 should be offered by the applying/system 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 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 applying 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 following session (by way of 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 by way of the refresh token name, a brand new refresh token is offered within the reply for the following session. The shopper is obligated to discard the previous API Token and retailer the brand new token for the following 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 under demonstration makes use of the API token to fetch the group info.
Further Notes
- 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.
- 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 so forth.
- Service accounts can allow automation to keep up worth add belongings as themselves.
- Duties initiated by service accounts are correctly attributed and occasions will determine them as actors.
- Like every principals, belongings could also be shared with or Service Account.
- The administrator can handle Service Accounts to vary the account function, software program ID, software program model, shopper URI, or quota restrictions.
- The administrator can revoke beforehand granted entry (just for Service Account should be in Granted or Lively stage). Upon revocation, the Service Account Stage adjustments to Created and the entry grant course of described in Step 4 should be redone.
- The administrator can delete the Service Account. Earlier than a Service Account will be deleted make it possible for 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 help and collaboration on this effort.