vCenter : déléguer le déploiement d’OVA sans droits admin

Le probleme qu’on resout

Les équipes applicatives ou projets ont régulièrement besoin de déployer des appliances virtuelles (OVA/OVF) : sondes, collecteurs, appliances réseau, images éditeurs. Donner le rôle Administrator global à ces opérateurs est une faute de sécurité : cela ouvre la configuration des hôtes, la suppression de VM, la gestion des permissions et l’accès à l’ensemble des datastores.

Les méthodes « évidentes » échouent pour deux raisons. D’abord, le rôle intégré Virtual Machine Power User ou Resource Pool Administrator ne couvre pas les privilèges de provisionnement d’OVF (notamment vApp.Import). Ensuite, le déploiement d’un OVA touche simultanément plusieurs familles d’objets : la VM/vApp cible, le datastore (allocation d’espace), le réseau (branchement du port group) et parfois le dossier VM. Si un seul de ces privilèges manque, l’assistant échoue avec un message peu explicite du type « Permission to perform this operation was denied ». L’objectif : un rôle minimal, assigné finement, qui autorise le déploiement et rien d’autre.

Comment ca marche

Le modèle d’autorisation vCenter repose sur trois notions : le privilège (action atomique, ex. Datastore.AllocateSpace), le rôle (collection de privilèges) et la permission (association rôle + utilisateur/groupe + objet d’inventaire, avec propagation optionnelle aux enfants).

Le déploiement d’OVF/OVA via le client vSphere ou PowerCLI (Import-VApp) consomme principalement ces privilèges :

• vApp.Import — importer une vApp/OVF (le privilège central).
• VirtualMachine.Config.AddNewDisk, VirtualMachine.Config.AddExistingDisk, VirtualMachine.Config.AddRemoveDevice, VirtualMachine.Config.AdvancedConfig — création des disques et périphériques.
• VirtualMachine.Inventory.Create — créer l’objet VM.
• VirtualMachine.Interact.PowerOn — si l’option « power on after deployment » est cochée.
• Datastore.AllocateSpace et Datastore.Browse — allouer l’espace et parcourir le datastore cible.
• Network.Assign — rattacher la VM au port group.
• Resource.AssignVMToPool — placer la VM dans le resource pool/cluster.

La bonne pratique consiste à créer un rôle regroupant ces privilèges, puis à poser plusieurs permissions ciblées : une sur le dossier VM de destination (propagée), une sur le datastore ou le dossier de datastores autorisé, une sur le réseau/port group, une sur le cluster/resource pool. On évite ainsi d’accorder le rôle à la racine (vCenter root) avec propagation, qui donnerait de fait accès à tout l’inventaire.

Prerequis

• vCenter Server 7.0 ou 8.0 (les noms de privilèges sont stables sur ces versions).
• Un compte disposant du privilège Authorization.ModifyPermissions et Authorization.ModifyRoles (typiquement un administrateur vCenter) pour créer le rôle et poser les permissions.
• Un groupe de sécurité (AD ou SSO vCenter) dédié aux opérateurs OVA, ex. EXEMPLE\gg-ova-deployers. On assigne à un groupe, jamais à des comptes nominatifs.
• PowerCLI 13.x installé : Install-Module VMware.PowerCLI -Scope CurrentUser.
• Connaissance des noms exacts d’inventaire cible : dossier VM, datastore (ou dossier de datastores), port group, cluster.

Procedure

1. Créer le groupe de sécurité dédié et y placer les opérateurs (hors scope PowerCLI ci-dessous).
2. Se connecter à vCenter en PowerCLI avec un compte habilité.
3. Créer le rôle personnalisé avec la liste de privilèges minimale.
4. Identifier les objets d’inventaire cibles (dossier VM, datastore, réseau, cluster).
5. Poser une permission du rôle sur chaque objet cible, avec propagation là où c’est pertinent (dossier VM : oui ; datastore : oui).
6. Faire tester un opérateur avec un OVA de validation et vérifier le succès.
7. Documenter dans le CMDB/wiki et versionner le script.

Le script

Script PowerCLI complet et commenté. Toutes les valeurs sont génériques : adaptez les variables en tête de fichier.

# ============================================================
# Delegation du deploiement OVA/OVF en moindre privilege
# Cree un role vCenter + permissions ciblees
# Valeurs generiques — a adapter avant execution
# ============================================================

#region Variables (a personnaliser)
$vcServer      = 'vcenter.exemple.test'
$roleName      = 'OVA-Deployer'
$securityGroup = 'EXEMPLE\gg-ova-deployers'   # groupe AD/SSO, pas un compte nominatif

# Objets d'inventaire cibles (noms exacts tels qu'affiches dans vSphere)
$targetVMFolder   = 'Projets-Appliances'   # dossier VM de destination
$targetDatastore  = 'ds-tier2-01'          # datastore autorise
$targetPortGroup  = 'pg-appliances-vlan20' # port group autorise
$targetCluster    = 'cl-prod-01'           # cluster / resource pool racine
#endregion

#region Connexion
# Ignorer le warning de certificat uniquement si PKI interne non approuvee (a eviter en prod)
Set-PowerCLIConfiguration -InvalidCertificateAction Warn -Confirm:$false | Out-Null
Connect-VIServer -Server $vcServer   # authentification interactive ou SSPI
#endregion

#region Liste des privileges minimaux pour l'import OVF/OVA
$privilegeIds = @(
    'VApp.Import'                              # privilege central d'import OVF
    'VirtualMachine.Inventory.Create'          # creer l'objet VM
    'VirtualMachine.Config.AddNewDisk'
    'VirtualMachine.Config.AddExistingDisk'
    'VirtualMachine.Config.AddRemoveDevice'
    'VirtualMachine.Config.AdvancedConfig'
    'VirtualMachine.Config.Resource'
    'VirtualMachine.Interact.PowerOn'          # si power-on apres deploiement
    'Datastore.AllocateSpace'
    'Datastore.Browse'
    'Network.Assign'
    'Resource.AssignVMToPool'
)
#endregion

#region Creation du role (idempotent)
$role = Get-VIRole -Name $roleName -ErrorAction SilentlyContinue
if (-not $role) {
    Write-Host "Creation du role $roleName..."
    $role = New-VIRole -Name $roleName -Privilege (Get-VIPrivilege -Id $privilegeIds)
} else {
    Write-Host "Role $roleName existant : mise a jour des privileges..."
    Set-VIRole -Role $role -AddPrivilege (Get-VIPrivilege -Id $privilegeIds) -ErrorAction SilentlyContinue | Out-Null
}
#endregion

#region Pose des permissions ciblees
# Fonction utilitaire : assigne le role sur une entite avec propagation
function Grant-Permission {
    param($Entity, [bool]$Propagate = $true)
    if (-not $Entity) { Write-Warning "Entite introuvable, permission ignoree."; return }
    New-VIPermission -Entity $Entity -Principal $securityGroup `
        -Role $role -Propagate $Propagate -ErrorAction Stop | Out-Null
    Write-Host "Permission posee sur : $($Entity.Name)"
}

# 1) Dossier VM de destination (propagation aux sous-dossiers)
Grant-Permission -Entity (Get-Folder -Name $targetVMFolder)   -Propagate $true

# 2) Datastore autorise (propagation pour allouer l'espace)
Grant-Permission -Entity (Get-Datastore -Name $targetDatastore) -Propagate $true

# 3) Port group / reseau
Grant-Permission -Entity (Get-VirtualPortGroup -Name $targetPortGroup) -Propagate $false

# 4) Cluster (resource pool racine) pour AssignVMToPool
Grant-Permission -Entity (Get-Cluster -Name $targetCluster) -Propagate $true
#endregion

Write-Host "Delegation OVA terminee." -ForegroundColor Green
Disconnect-VIServer -Server $vcServer -Confirm:$false

Variante : exporter le rôle pour versionnage Git et le réimporter sur un autre vCenter.

# Export du role vers un fichier (audit / portabilite)
Get-VIRole -Name 'OVA-Deployer' |
    Select-Object Name, @{N='Privileges';E={$_.PrivilegeList -join ';'}} |
    Export-Csv -Path '.\role-ova-deployer.csv' -NoTypeInformation -Encoding UTF8

# Reimport sur un autre vCenter
$privs = (Import-Csv '.\role-ova-deployer.csv').Privileges -split ';'
New-VIRole -Name 'OVA-Deployer' -Privilege (Get-VIPrivilege -Id $privs)

Validation

Trois niveaux de vérification :

• Côté rôle : Get-VIRole -Name 'OVA-Deployer' | Select -Expand PrivilegeList doit lister les privilèges ci-dessus et uniquement ceux-là.
• Côté permission : Get-VIPermission -Principal 'EXEMPLE\gg-ova-deployers' doit retourner une ligne par objet ciblé (dossier VM, datastore, port group, cluster), avec le rôle OVA-Deployer et Propagate cohérent.
• Test fonctionnel : un membre du groupe déploie un OVA de référence avec Import-VApp et doit réussir sans erreur de permission :

# Execute par un operateur membre du groupe (droits minimaux)
Connect-VIServer -Server 'vcenter.exemple.test'
$vmhost = Get-Cluster 'cl-prod-01' | Get-VMHost | Select-Object -First 1
Import-VApp -Source 'C:\OVA\appliance-test.ova' `
    -VMHost $vmhost `
    -Datastore (Get-Datastore 'ds-tier2-01') `
    -Location (Get-Folder 'Projets-Appliances') `
    -DiskStorageFormat Thin -Confirm:$false

Résultat attendu : création de la VM/vApp sans message « Permission to perform this operation was denied ». Tout autre opération (suppression d’une VM tierce, modification d’un hôte) doit être refusée.

Plan de retour (rollback)

Retrait non destructif, dans l’ordre : d’abord les permissions, puis le rôle une fois qu’il n’est plus référencé.

Connect-VIServer -Server 'vcenter.exemple.test'

# 1) Retirer les permissions posees pour le groupe
Get-VIPermission -Principal 'EXEMPLE\gg-ova-deployers' |
    Where-Object { $_.Role -eq 'OVA-Deployer' } |
    Remove-VIPermission -Confirm:$false

# 2) Supprimer le role (echoue si encore reference, ce qui est une securite)
Remove-VIRole -Role (Get-VIRole -Name 'OVA-Deployer') -Force:$false -Confirm:$false

Disconnect-VIServer -Confirm:$false

Si vous devez conserver l’historique, préférez retirer les membres du groupe plutôt que supprimer rôle et permissions : c’est réversible instantanément côté annuaire.

Depannage

Securite, changement et bonnes pratiques

• Moindre privilège strict : n’ajoutez un privilège qu’après avoir prouvé qu’un déploiement échoue sans lui. Retirez VirtualMachine.Interact.PowerOn si vous imposez un power-on manuel contrôlé.
• Assignation par groupe : jamais de permission sur un compte nominatif. La gestion des membres se fait dans l’annuaire, auditable et réversible.
• Portée réduite : ciblez un dossier VM projet et un datastore de tier adapté, pas le datacenter entier. Évitez toute permission à la racine vCenter.
• Secrets : pas de mot de passe en clair dans les scripts planifiés. Utilisez New-VICredentialStoreItem ou un coffre (CyberArk, Azure Key Vault) et un compte de service dédié en lecture seule pour l’audit.
• Audit : exportez périodiquement le rôle et les permissions (bloc d’export ci-dessus) et versionnez-les en Git pour détecter toute dérive.
• Cadrage ITIL : la première mise en place est un changement normal à passer en CAB (impact sur le modèle d’autorisation vCenter). Après validation et rédaction de la procédure, les ajouts d’objets ciblés deviennent un changement standard préautorisé, exécutable hors fenêtre de maintenance car non disruptif pour la production. Documentez le risque (sur-privilège) et le rollback dans l’enregistrement de changement. Rattachez toute demande d’accès d’un nouvel opérateur au processus de gestion des demandes (ajout au groupe de sécurité).

A retenir

Déléguer le déploiement d’OVA ne nécessite pas d’accorder les droits administrateur. En créant un rôle vCenter contenant les douze privilèges d’import OVF et en le posant sur les seuls objets cibles (dossier VM, datastore, réseau, cluster), on obtient une délégation sûre, auditable et reproductible via PowerCLI. La méthode respecte le moindre privilège, se versionne en Git et se retire proprement en cas de besoin.

Prochaine étape : adaptez les variables du script à un environnement de pré-production, validez avec un OVA de référence, puis soumettez la mise en place au CAB avec la procédure de rollback jointe.