Aller au contenu principal

Migration des scripts: de vRA 8.x vers VCF Automation 9.1

· 6 minutes de lecture
DSO Conseils
Conseil & Architecture VMware

Objectif: migrer les scripts vRA 8.x vers VCF Automation 9.1, sans perte de fonctionnalite sur la chaine d'authentification.

Le besoin de base reste identique: obtenir un refresh token, puis generer un access token exploitable dans les appels API. En revanche, le mecanisme historique de creation du refresh token en vRA 8.x n'est plus la reference cible en VCF Automation 9.1.

1. Point de depart en vRA 8.x​

Dans les scripts historiques vRA 8.x, le schema etait generalement le suivant:

  1. creation du refresh token via login utilisateur
  2. creation du bearer token via endpoint d'autorisation
  3. appels API metier

Exemple de creation de refresh token en vRA 8.x:

POST {{vra}}/csp/gateway/am/api/login?access_token
Content-Type: application/json

{
  "username": "{{username}}",
  "password": "{{password}}"
}

Puis generation du bearer token:

POST {{vra}}/csp/gateway/am/api/auth/api-tokens/authorize?refresh_token={{refresh_token}}
Accept: application/json

Ce mecanisme explique la structure de nombreux scripts existants.

2. Ce qui change en VCF Automation 9.1​

En cible VCF Automation 9.1, la creation initiale du refresh token ne repose plus sur le meme usage login/password des anciens scripts.

Il existe maintenant deux methodes possibles:

  1. methode API Token utilisateur
  2. methode Service Account

Les deux methodes permettent ensuite de generer un access token via OAuth.

3. Methode A: API Token utilisateur​

Cette methode est adaptee pour les tests, les validations rapides et les usages personnels.

Actions IHM​

Dans l'organisation cible:

  1. ouvrir le menu utilisateur
  2. ouvrir My Account
  3. ouvrir API Tokens
  4. cliquer New
  5. nommer le token
  6. cliquer Create
  7. copier immediatement la valeur affichee

Le token affiche est a conserver dans le gestionnaire de secrets. Dans ce flux, il est utilise comme refresh token.

Appel OAuth pour obtenir le bearer token​

POST {{vra}}/tm/oauth/tenant/{{org}}/token
Content-Type: application/x-www-form-urlencoded
Accept: application/json

grant_type=refresh_token&refresh_token={{api_token_utilisateur}}

Selon l'environnement, l'endpoint fonctionnel peut etre /oauth/tenant/{{org}}/token ou /tm/oauth/tenant/{{org}}/token. La pratique recommandee consiste a standardiser un seul endpoint valide dans les scripts.

4. Methode B: Service Account (cible recommandee)​

Pour une automatisation durable (jobs planifies, pipelines CI/CD, integrations), cette methode constitue la cible prioritaire.

4.1 Creation du Service Account dans l'IHM​

Dans l'organisation VCF Automation cible:

  1. ouvrir Infrastructure
  2. ouvrir Access Control
  3. ouvrir Service Accounts
  4. cliquer New
  5. renseigner Name
  6. attribuer les Roles necessaires
  7. renseigner Client Version
  8. renseigner Client URL
  9. generer Software ID si demande
  10. finaliser la creation

Etat attendu apres creation: Created.

4.2 Recuperer la bonne valeur d'identite​

Dans la ligne du Service Account:

  1. deplier le detail
  2. copier Client ID

Point critique: utiliser Client ID pour OAuth, et non Software ID.

4.3 Demander l'autorisation (device authorization)​

@vra = https://vcfa.example.com
@org = vcfa
@client_id = remplacer_par_client_id

###
# @name DemandeAutorisation
POST {{vra}}/oauth/tenant/{{org}}/device_authorization
Content-Type: application/x-www-form-urlencoded
Accept: application/json

client_id={{client_id}}

La reponse contient notamment device_code et user_code.

4.4 Validation manuelle dans l'IHM​

Toujours dans:

  1. Infrastructure
  2. Access Control
  3. Service Accounts
  4. Review Access Requests

Puis:

  1. coller le user_code
  2. cliquer Lookup
  3. verifier la demande
  4. cliquer Grant

Etat attendu: Granted.

4.5 Echange initial pour obtenir refresh token + access token​

###
# @name CreationTokensServiceAccount
POST {{vra}}/oauth/tenant/{{org}}/token
Content-Type: application/x-www-form-urlencoded
Accept: application/json

grant_type=urn:ietf:params:oauth:grant-type:device_code&client_id={{client_id}}&device_code={{device_code}}

Points de controle:

  1. utiliser device_code (pas user_code)
  2. utiliser le meme org
  3. utiliser le meme client_id

5. Renouvellement standard dans les scripts cible 9.1​

Une fois le refresh token disponible, les scripts doivent utiliser:

POST {{vra}}/oauth/tenant/{{org}}/token
Content-Type: application/x-www-form-urlencoded
Accept: application/json

grant_type=refresh_token&refresh_token={{refresh_token}}

Le champ access_token est le bearer token a envoyer dans les appels API.

6. Rotation des refresh tokens (point cle)​

Si la rotation est active, chaque renouvellement du Bearer Token renvoi un nouveau refresh token.

  1. Tant que vous utilisez l'ancien refresh token, le meme refresh token sera propose dans la reponse.
  2. A la premiere utilisation du nouveau refresh token, l'ancien est desactive.
  3. Il est donc necessaire de sauvegarder le nouveau refresh token des sa premiere utilisation, et de prevoir cette action avant la fin de vie du refresh token.

7. Modifications concretes a appliquer dans les scripts​

7.1 Endpoints​

Remplacer les appels historiques:

  1. /csp/gateway/am/api/login?access_token
  2. /csp/gateway/am/api/auth/api-tokens/authorize

Par les endpoints OAuth 9.1:

  1. /oauth/tenant/{org}/device_authorization
  2. /oauth/tenant/{org}/token

7.2 Format des requetes​

Pour OAuth:

  1. utiliser Content-Type: application/x-www-form-urlencoded
  2. ne pas envoyer ces appels en JSON

7.3 Variables de configuration​

A introduire ou normaliser dans les scripts:

  1. vra_base_url
  2. org
  3. client_id (si Service Account)
  4. refresh_token courant

7.4 Securite et observabilite​

  1. ne jamais journaliser access_token ou refresh_token en clair
  2. eviter les renouvellements concurrents avec la meme valeur
  3. ajouter des controles explicites sur le code HTTP et la presence des champs token

8. Exemple REST Client complet (base cible)​

@vra = https://vcfa.example.com
@org = vcfa
@client_id = remplacer_par_client_id
@device_code = remplacer_par_device_code
@refresh_token = remplacer_par_refresh_token

###
# Etape 1 - Demande d'autorisation Service Account
POST {{vra}}/oauth/tenant/{{org}}/device_authorization
Content-Type: application/x-www-form-urlencoded
Accept: application/json

client_id={{client_id}}

###
# Etape manuelle IHM
# Infrastructure > Access Control > Service Accounts
# Review Access Requests > user_code > Lookup > Grant

###
# Etape 2 - Echange initial
POST {{vra}}/oauth/tenant/{{org}}/token
Content-Type: application/x-www-form-urlencoded
Accept: application/json

grant_type=urn:ietf:params:oauth:grant-type:device_code&client_id={{client_id}}&device_code={{device_code}}

###
# Etape 3 - Renouvellement standard
POST {{vra}}/oauth/tenant/{{org}}/token
Content-Type: application/x-www-form-urlencoded
Accept: application/json

grant_type=refresh_token&refresh_token={{refresh_token}}

> {%
  client.global.set("access_token", response.body.access_token);
  client.global.set("refresh_token", response.body.refresh_token);
%}

###
# Etape 4 - Appel API metier
GET {{vra}}/iaas/api/projects
Authorization: Bearer {{access_token}}
Accept: application/json

9. Conclusion​

La migration vRA 8.x vers VCF Automation 9.1 doit remplacer le flux historique de creation du refresh token par un flux OAuth cible, en choisissant explicitement l'une des deux methodes:

  1. API Token utilisateur pour les usages simples et de test
  2. Service Account pour les automatisations durables

La stabilite de la cible repose sur trois exigences:

  1. endpoints OAuth corrects
  2. format application/x-www-form-urlencoded respecte
  3. gestion rigoureuse de la rotation des refresh tokens