Gestion des comptes de service dans VMware Cloud Director

Vous pouvez automatiser l'accès des applications tierces à VMware Cloud Director à l'aide de comptes de service.

Partage

À partir de VMware Cloud Director 10.4.1, si vous souhaitez limiter les informations de compte de service que les utilisateurs peuvent voir, vous pouvez accorder à certains rôles uniquement le droit Affichage des comptes de service limités. Lorsqu'un utilisateur disposant du droit Affichage des comptes de service limités effectue une demande GET sur le compte de service, dans la réponse, les éléments softwareId, softwareVersion, uri et status du compte de service apparaissent comme null.

Implémentation

Pour fournir un accès automatisé à VMware Cloud Director, les comptes de service utilisent des jetons d'API. Les comptes de service sont destinés à un accès basé sur API uniquement. Une fois que vous accordez l'accès à un compte de service, l'application cliente authentifiée reçoit son jeton d'API, qui est un jeton d'actualisation OAuth, ainsi qu'un jeton d'accès, qui représente sa première session VMware Cloud Director, pour une utilisation immédiate. Les applications ont besoin des jetons d'API pour l'authentification avec VMware Cloud Director. Les jetons d'accès sont des jetons de session (jetons JWT) VMware Cloud Director que les applications utilisent pour effectuer des demandes d'API à l'aide du compte de service. Les comptes de service des applications utilisent des jetons d'API et, par conséquent, ont les mêmes restrictions que les jetons d'API utilisateur dans VMware Cloud Director.

L'accès aux comptes de service est accordé à l'aide de l'élément « Demander l'autorisation du compte de service ». Cela garantit que seule l'application qui doit utiliser le jeton dispose d'un accès unique au jeton et peut l'utiliser. Aucun autre acteur ne peut accéder au jeton. En tant qu'administrateur, vous gérez l'accès au compte de service. Cependant, même les administrateurs n'ont pas accès au jeton réel qui accorde l'accès. VMware Cloud Director donne le jeton uniquement au compte de service. Pour ce faire, VMware Cloud Director utilise une norme connue. Pour garantir la synchronisation, entre vous et l'application à laquelle vous accordez le jeton, via l'octroi et la transmission du jeton, vous ne pouvez initier le processus d'octroi de jeton d'API que si vous connaissez le code utilisateur de l'application.

Contrairement aux jetons d'API utilisateur, les jetons d'API accordés aux comptes de service changent à chaque utilisation, conformément à la section 6 de la RFC 6749. Les jetons d'API de compte de service inutilisés n'expirent jamais, sauf si vous les révoquez.

Les comptes de service ne peuvent avoir qu'un seul rôle. Dans les API compatibles OAuth, le rôle est communiqué via le champ d'étendue en tant qu'URN (Uniform Resource Name) encodé par URL avec le nom du rôle. Le format de l'URN est urn:vcloud:role:[roleName]. Reportez-vous à la RFC 8141, qui décrit le codage URN.

Note : Le point de terminaison du terminal n'est pas authentifié. Envisagez de configurer des règles de limitation spéciales au niveau de votre équilibrage de charge.

Tableau 1. État des comptes de service
Status	Description
Créé	Le compte se trouve dans l'état initial après la création.
Demandé	Un demandeur a initié une ou plusieurs demandes d'accès en attente à l'aide d'une demande d'autorisation de terminal.
Accordé	Un administrateur a donné son accord à une demande en attente et attend l'interrogation du compte de service et l'extraction du jeton d'API.
Actif	Le compte de service a extrait le jeton d'API et peut accéder à VMware Cloud Director à l'aide du jeton.

Limitations

Étant donné que l'utilisation des comptes de service est destinée à des applications tierces, les comptes de service présentent certaines limitations.

Lorsque vous utilisez des comptes de service, les applications ne peuvent pas effectuer certaines tâches.

Effectuer des tâches de gestion des utilisateurs
Créer des jetons d'API
Gérer d'autres comptes de service

Lorsqu'elles accèdent à VMware Cloud Director à l'aide d'un compte de service, les applications disposent uniquement de droits d'affichage pour les ressources suivantes.

Utilisateur
Groupe
Rôles
Rôles globaux
Bundles de droits

Les applications qui accèdent à VMware Cloud Director à l'aide d'un compte de service ne disposent pas des droits suivants.

Jeton : Gérer
Jeton : Gérer tous

Multisite

À partir de VMware Cloud Director 10.4.1, les comptes de service peuvent gérer et surveiller plusieurs installations ou groupes de serveurs VMware Cloud Director distribués géographiquement et leurs organisations en tant qu'entités uniques à l'aide de la fonctionnalité multisite. Pour plus d'informations, reportez-vous à la section Configuration et gestion des déploiements multisite. Si un compte de service fait une demande à une organisation différente de celle sur laquelle il est authentifié, vérifiez que le compte de service existe dans l'organisation associée et qu'il a le même nom et le même ID logiciel. Vous devez également inclure un en-tête X-VMWARE-VCLOUD-AUTH-CONTEXT qui spécifie le nom de l'organisation qui doit répondre à votre demande. Reportez-vous aux informations sur la configuration et la gestion des déploiements multisite dans le Guide de programmation de VMware Cloud Director API.

Créer un compte de service à l'aide de votre VMware Cloud Director Service Provider Admin Portal

Vous pouvez créer un compte pour un accès automatisé à VMware Cloud Director à l'aide du Service Provider Admin Portal.

Procédure

Dans le panneau de navigation de gauche principal, sélectionnez Administration.
Dans le panneau de gauche, sous Contrôle d'accès au fournisseur, sélectionnez Comptes de service.
Cliquez sur Nouveau.
Entrez un nom pour le compte de service.
Dans le menu déroulant Attribuer un rôle, sélectionnez un rôle pour le compte de service.
La liste des rôles disponibles comprend les rôles d'organisation du système local ou, s'il s'agit d'une organisation de locataires, les rôles globaux publiés dans l'organisation en plus des rôles locaux du locataire.
Entrez un ID de logiciel pour le compte de service ou générez-en un et entrez-le à l'aide du bouton Générer un ID de logiciel.

Les comptes de service doivent disposer d'ID de logiciels qui sont des identifiants uniques, au format UUID, représentant le logiciel qui se connecte à VMware Cloud Director. Cet ID est le même pour toutes les versions et instances d'un logiciel.

Pour les solutions plus importantes, afin de conserver le contrôle sur l'identité de vos comptes de service, n'utilisez pas l'option Générer un ID de logiciel et générez votre propre ID de logiciel.
(Facultatif) Entrez la version du logiciel du système utilisant le compte de service.
La version du logiciel est un élément d'information facultatif spécifié par le fournisseur des métadonnées associées au compte de service. Pour suivre le moment où un logiciel est modifié, VMware Cloud Director utilise la version du logiciel. La version du logiciel peut être utile pour identifier un compte de service.
(Facultatif) Entrez un URI client.
L'URI (Uniform Resource Identifier) du client est une URL qui permet d'accéder à la page Web du fournisseur et fournit des informations sur le client.
Cliquez sur Suivant.
(Facultatif) Ajoutez des quotas sur les ressources que vous souhaitez voir gérées par le compte de service.
Ces quotas limitent la capacité du compte de service à consommer des ressources de stockage et de calcul.
Vérifiez les informations du compte de service et cliquez sur Terminer.

Résultats

Le compte de service figure sur la page Comptes de service avec l'état Created.

Exemple

Vous pouvez également créer un compte de service à l'aide de l'API VMware Cloud Director. La demande d'API utilise le même point de terminaison d'API que la création d'un jeton d'API utilisateur, mais la présence du champ software_id indique l'intention de créer un compte de service.

Exemple de demande :

POST /oauth/provider/register 

Accept:application/json

Content-Type:application/json

Authorization:Bearer eyJhbGciOiJSUzI...7g7rA 

Body: { 

    "client_name": "exampleServiceAccount", 

    "software_id": "bc2528fd-35c4-44e5-a55d-62e5c4bd9c99", 

    "scope": "urn:vcloud:role:System%20Administrator", 

    "client_uri": "https://www.companyname.com", 

    "software_version": "1.0" 

}

Exemple de réponse :

{ 

"client_name": "exampleServiceAccount", 

"client_id": "734e3845-1573-4f07-9b6c-b493c9042187", 

"grant_types": [ 

"urn:ietf:params:oauth:grant-type:device_code" 

], 

"token_endpoint_auth_method": "none", 

"client_uri": "https://www.company_name.com", 

"software_id": "bc2528fd-35c4-44e5-a55d-62e5c4bd9c99", 

"software_version": "1.0", 

"scope": "urn:vcloud:role:System%20Administrator" 

}

Que faire ensuite

Copiez l'ID client qui s'affiche dans les détails du compte de service. Pour accorder l'accès au compte de service, vous devez utiliser l'ID client.

Accorder l'accès à un compte de service à l'aide de votre VMware Cloud Director Service Provider Admin Portal

Une fois que vous avez créé un compte de service et que l'application demande l'autorisation de recevoir un jeton d'accès, vous pouvez accorder le jeton à l'aide du VMware Cloud Director Service Provider Admin Portal.

Note : Si le délai d'expiration expire au cours de cette procédure, l'état du compte de service dans Service Provider Admin Portal redevient Created et vous devez recommencer la procédure.

Conditions préalables

Copiez l'ID client à partir des détails du compte de service dans le Service Provider Admin Portal.

Vérifiez que l'application qui demande le compte effectue une demande d'autorisation du terminal OAuth 2.0 conforme à la norme RFC sur le point de terminaison d'API https://site.cloud.example.com/oauth/provider/device_authorization. Pour plus d'informations sur les demandes d'autorisation de terminal, reportez-vous à la section 3.1 de la RFC 8628.

Clé	Valeur
`client_ID`	`Generated_Client_ID`

Une fois que l'application demande l'accès, l'état du compte de service dans le Service Provider Admin Portal devient Requested. L'application reçoit le code du terminal, le code utilisateur et des informations supplémentaires.

Exemple de demande :

POST /oauth/provider/device_authorization
Accept:application/json 
Content-Type: application/x-www-form-urlencoded
Body:
client_id=734e3845-1573-4f07-9b6c-b493c9042187

Exemple de réponse :

{
"device_code": "tkhZ0uoUMy5xgjJqRJblIq3-g44xy2Ms6TEpv3Z_fKw",
"user_code": "3VL8-SQVJ",
"verification_uri": "https://[VCD]/provider/administration/access-control/service-accounts",
"expires_in": 3600,
"interval": 60
}

Le terminal doit effectuer des interrogations à la fréquence spécifiée dans la réponse ci-dessus (en secondes) /oauth/provider/token , conformément à la RFC. Le terminal doit utiliser le code du terminal jusqu'à ce qu'il reçoive les jetons de VMware Cloud Director. Sinon, la demande expire.

Exemple de demande :

POST: /oauth/provider/token
Accept:application/json 
Content-Type: application/x-www-form-urlencoded
Body:
client_id= 734e3845-1573-4f07-9b6c-b493c9042187&grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Adevice_code&device_code=tkhZ0uoUMy5xgjJqRJblIq3-g44xy2Ms6TEpv3Z_fKw

Exemple de réponse avant l'autorisation :

{
    "error": "authorization_pending",
    "error_description": "Device authorization request pending",
    "error_uri": null,
    "minorErrorCode": "authorization_pending",
    "message": "Device authorization request pending",
    "stackTrace": null
}

Exemple de réponse après accord :

{
    "access_token": "eyJhbGciOiJSU…HqJaDud1sVA",
    "token_type": "Bearer",
    "expires_in": 2592000,
    "refresh_token": "SsybukUed8SBP2p1AaFiGJhrntQNWZVX"
}

Si vous ne confirmez pas ou ne refusez pas une demande d'accès, le code utilisateur peut expirer. Le délai d'expiration s'affiche dans la réponse à la demande d'autorisation du périphérique.

VMware Cloud Director accorde un jeton d'API principal à l'application uniquement si l'application et l'administrateur utilisent le code du terminal et le code utilisateur correspondant l'un à l'autre.

Obtenez le code utilisateur de l'application. Vous devez entrer le code à l'étape 4.

Procédure

Dans le panneau de navigation de gauche principal, sélectionnez Administration.
Dans le panneau de gauche, sous Contrôle d'accès au fournisseur, sélectionnez Comptes de service.
Cliquez sur Vérifier les demandes d'accès.
Entrez le code utilisateur de l'application que vous avez obtenu dans le point 3 des conditions préalables, cliquez sur Recherche, puis vérifiez les détails de l'accès demandé.
Accordez l'accès à l'application.
Si vous refusez l'accès à l'application, l'état du compte de service dans Service Provider Admin Portal redevient Created.

Résultats

L'état de la demande de service devient Granted. VMware Cloud Director accorde à l'application liée au compte de service son jeton d'API principal sous la forme d'un jeton d'API. La réponse, telle que requise par la RFC, est un jeton d'accès OAuth représentant une session utilisateur pour une utilisation immédiate par le compte de service. Si l'application n'utilise pas immédiatement le jeton d'accès OAuth, la session expire conformément au délai d'expiration de session inactive configuré. Le compte de service peut également se déconnecter explicitement, ce qui est recommandé non seulement pour des raisons de sécurité, mais également pour fournir une bonne exécution de test afin que le compte de service effectue un appel d'API à VMware Cloud Director. Une fois que l'application a extrait le jeton d'API, l'état devient Active.

Que faire ensuite

Pour modifier le rôle de compte de service, l'ID du logiciel, la version du logiciel, l'URI du client ou les restrictions de quota attribués, sélectionnez un compte de service et cliquez sur Modifier un compte de service. Les modifications prennent effet lors de la prochaine actualisation du jeton.
Pour révoquer l'accès au compte de service afin que le jeton d'API accordé à ce dernier devienne non valide, cliquez sur Révoquer. VMware Cloud Director met fin à toutes les sessions actives. La révocation d'un jeton d'API ne supprime pas le compte de service. Toutefois, l'état du compte devient Created. Si l'application a déjà redemandé l'accès, l'état du compte de service devient Requested. Vous devez à nouveau suivre la procédure pour accorder l'accès au compte de service afin que le compte devienne Active.