[ARTICLE] [VCENTER] [PART 1] Migration du Native Key Provider (NKP) vers un KMS Externe

J’ai récemment été confronté à un besoin de sécurité lié à une homologation, et afin de répondre aux exigences de cette homologation il faut migrer l’ensemble des workloads chiffrés sur le NKP (Native Key Provider) du vCenter sur un KMS Externe, et ce en prenant en compte qu’il ne faut pas que les clients aient le moindre impact de service.
(dans la limite de tout problème éventuel: prochain post sur le sujet en part 2).

Versions utilisées:

vCD : 10.3.2.19173133
vCenter : 7.0.3.00700
ESXi : 7.0.3.19482537

Prérequis:

• Installer les modules PowerCLI & VMware.VMEncryption
• Backup du NKP en cas de rollback éventuel
• VIP KMS (à faire avec un AVI LB par exemple)
  • La VIP est obligatoire parce que le vCenter requête continuellement les 2 KMS, et s’il en détecte 1 KO il rendra le cluster automatiquement inutilisable et donc toute nouvelle création de VM sera impossible. Le contournement est d’utiliser une VIP directement sur le vCenter.
• Tests de résilience du KMS effectués
• Vérification de la Storage Policy porteur du chiffrement
  • Vérification du Storage Comptatibility

Nous avons 2 choix possibles pour re-chiffrer des VMs d’un Key Provider vers un autre (Native Key Provider vers Standard KMS ou inversement).

Migration des workloads du NKP vers le KMS Externe

Méthode manuelle (VM par VM):

Cette méthode est la plus rapide si vous n’avez d’environnement prêt avec les modules PowerCLI & VMware.VMEncryption, et seulement si vous avez quelques dizaines de VMs à migrer.

Aussi, elle est possible seulement si vos nouveaux workloads peuvent d’ores et déjà être hébergés sur le KMS Externe.

• Passage du KMS Externe en “default”

• Rekey de chaque VM

• Suppression de l’ancien NKP (garder le backup en cas de rollback)

Méthode PowerCLI (VM par VM):

Cette méthode est la plus rapide, et surtout elle est mandatory si vous ne pouvez pas passer le KMS Externe en default côté vCenter (pour une raison fonctionnelle ou technique par exemple).

• Passage du KMS Externe en “default” depuis le vCenter

• Migration des workloads sur le NKP vers le KMS Externe

Get-VM "votreVM"| Set-VMEncryptionKey -KMSClusterId "votreKMS"

• Suppression de l’ancien NKP (garder le backup en cas de rollback)

Migration des workloads du KMS Externe vers le NKP

Petite subtilité sur la migration vers le NKP, la commande n’est plus la même et dépend cette fois-ci directement de VMware.PowerCLI

$NKP = Get-KeyProvider "votreNKP"
Set-VM "votreVM" -KeyProvider $NKP

Liste des tests effectués et de leur résultat

Avant de commencer, l’ensemble de ces tests ont été effectués sur une infra de lab pour confirmer la faisabilité/non faisabilité des tests avant une MEP officielle. Ne soyez pas surpris si des tests paraissent “logique” et sont “KO”

• Backup “NKP”
  • Obligatoire pour l’utiliser => OK
• Shutdown du vCenter porteur du “NKP” (Per-VM)
  • Aucune perte de connexion sur les VMs seulement si les hosts sont UP (KEK en cache sur l’ESXi), sinon dans le cas contraire nous avons un problème lié au vSAN car l’host ne trouve plus le .vmx ce qui est logique parce que la VM est chiffrée:

• Suppression “NKP” + reboot du vCenter (Cluster Encryption)
  • Comme le test précédent, aucune perte côté VM sauf si reboot des hosts:

• Suppression et restauration du “NKP”
  • Les hosts se comportent correctement, les KEK sont bien poussées sur chaque ESXi et les VMs sont automatiquement déchiffrées:

• Restore du vCenter et du NKP via le VCSA Deploy (clean restore)
  • Toutes les VMs peuvent être dechiffrées après que le NKP soit bien reconnu
• Création d’une VM sur un vCenter porteur d’un NKP puis migration de cette VM sur un vCenter n’ayant pas le NKP source:

• Import du NKP source:

Conclusion

Nous avons vu comment migrer ses workloads d’un KMS Externe vers un NKP (ou inversement).
Avant toute chose rappelez-vous que les prérequis cités en début d’article sont très important, un rollback dans le cadre d’une migration est très critique (perte d’accès possible aux workloads). C’est d’ailleurs ce que nous allons voir en partie 2

Sources:
vSAN Encryption Services
https://core.vmware.com/resource/vsan-encryption-services
How vSphere Virtual Machine Encryption Protects Your Environment
https://docs.vmware.com/en/VMware-vSphere/7.0/com.vmware.vsphere.security.doc/GUID-8D7D09AC-8579-4A33-9449-8E8BA49A3003.html
Using Encryption in a vSAN Cluster
https://docs.vmware.com/en/VMware-vSphere/7.0/com.vmware.vsphere.vsan.doc/GUID-F3B2714F-3406-48E7-AC2D-3677355C94D3.html
Rekey an Encrypted Virtual Machine Using the CLI
https://docs.vmware.com/en/VMware-vSphere/8.0/vsphere-security/GUID-E24D65FA-88F0-4724-AAC3-32BCCC2BEC28.html