Un solo posto per certificati e password

In VCF 9.0 il punto d’ingresso non è più la UI di SDDC Manager ma la console di VCF Operations. Certificati e password vivono entrambi sotto Fleet Management, in Certificates e in Passwords, e in entrambi i casi la prima scelta è lo scope: VCF Management, cioè i componenti di fleet (VCF Operations, VCF Automation, VCF Operations for Logs e for Networks, VCF Identity Broker), oppure VCF Instances, dove si sceglie l’istanza o il dominio e si agisce sui componenti core — SDDC Manager, vCenter, NSX Manager, ESX. L’interruttore Show ESX Hosts nasconde i certificati degli host; serve comunque il ruolo Administrator.

Configurare la CA e sostituire un certificato

Prima di rinnovare serve una CA: il pulsante Configure CA apre il modulo. Per una Microsoft Certificate Authority servono la CA Server URL (deve iniziare per https:// e finire per /certsrv), un account di servizio a privilegi minimi e il Template Name del template di emissione; la CA dev’essere raggiungibile e in sincronia oraria. In alternativa, e solo per lo scope VCF Instances, si può usare OpenSSL: per i componenti VCF Management l’unica CA supportata è Microsoft.

Sul componente il menu a tre puntini offre Generate CSR — con Subject Alternative Name e Key Size 2048 o 4096, gli host ESX solo 2048 — e Replace With Configured CA Certificate. Se la firma la fa una CA esterna, si scarica la CSR e si torna su Import Certificate: sono accettati solo certificati PEM, mentre la catena può arrivare come .crt, .cer, .pem, .p7b o .p7c. Poi Validate, Save e Replace With Imported Certificate.

Il rinnovo ha due strade. Manuale, con Renew Certificate, per certificati VMCA, Microsoft CA, OpenSSL o self-signed — mai per i root. Automatica, con il toggle Activate Auto-renewal: scatta 60 giorni prima della scadenza e copre solo i componenti che supportano un aggiornamento non disruptivo.

Password: tre verbi che non sono sinonimi

VCF distingue account locali del sistema operativo (vcf, root, backup su SDDC Manager; root, admin, audit su NSX), account applicativi come admin@local, e service account come svc-vcf-ESX-<hostname>, system managed: ruotano da soli ogni 30 giorni e non si toccano a mano.

Da Fleet Management → Passwords, Update Password imposta la password che scegli tu. Remediate Password è tutt’altro: sincronizza il valore memorizzato in SDDC Manager con quello reale del componente, ed è il rimedio a un cambio out-of-band o a un workflow fallito. Entrambe pretendono che non ci siano workflow falliti o in corso. La rotazione è documentata sul percorso Security → Password Management di SDDC Manager: genera una password casuale conforme alla policy del componente e ricostruisce le integrazioni; la UI offre intervalli preimpostati, l’API quelli personalizzati. Gli account ESX si possono ruotare, ma la rotazione pianificata non è supportata. Per leggere le credenziali, SSH su SDDC Manager come utente vcf e comando lookup_passwords: restituisce i componenti di una istanza VCF, non quelli VCF Management. L’equivalente API è GET /v1/credentials.

Importare un vCenter esistente

Il percorso è Inventory → Detailed View, espandi VCF Instances, selezioni l’istanza, Add Workload Domain → Import a vCenter. Prerequisiti: SSH abilitato sul vCenter, host ESX registrati con FQDN e non con nome breve, vCenter e ESX almeno 8.0 Update 1, NSX Manager almeno 4.2. Il wizard chiede il nome del dominio e se prendere un vCenter standalone già in inventario o specificarne uno esterno; se NSX è già collegato si danno VIP FQDN e password admin/root/audit, con la casella Enable Edge cluster sync and import NSX Edge node VMs. Seguono thumbprint e prechecks e, se NSX non esiste, il deploy in dimensione Standard (nodo singolo, solo con vCenter 9.0 o superiore) o High-Availability a tre nodi. Due limiti che l’esame ama: tutti i cluster del vCenter si importano insieme; e restano fuori vCenter in Enhanced Linked Mode, VxRail, cluster gestiti con baseline o vSphere Configuration Profiles e DRS non completamente automatico. Se qualcuno modifica vCenter o NSX fuori banda, l’inventario si riallinea con Actions → Sync Inventory.

Ciclo di vita: prima il fleet, poi l’istanza

Il lifecycle si governa da Fleet Management → Lifecycle, con binari da un depot online o offline; senza depot si usa il VCF Download Tool, una CLI. L’ordine è vincolante: la VCF Operations fleet management appliance va aggiornata prima di ogni altro componente di management, e solo dopo si passa ai core component, prima nel management domain e poi nei workload domain. Sui domini il flusso è Precheck → Plan Patching → Validate Selection → Confirm → Done → Schedule Update o Update Now, e non si crea un piano di patching se ne esiste già uno di upgrade. Il Flexible BOM upgrade lascia scegliere la versione target di ciascun componente core, e il sistema ne deriva la sequenza. Scattano poi i resource lock: SYSTEM blocca tutte le operazioni Day-N dell’istanza (è il caso del management domain), DOMAIN e CLUSTER confinano il blocco; backup/restore, rotazione certificati (tranne ESX) e upgrade di SDDC Manager restano comunque bloccati.

Trappole tipiche d’esame

  • VCF non è VMware vSphere Foundation. In VVF la console VCF Operations gestisce i certificati del solo componente VCF Operations; la gestione a fleet, con i due scope, è di VCF.
  • Import ≠ converge. Import a vCenter crea un workload domain da un vCenter esistente; la convergenza usa l’infrastruttura esistente per creare il management domain di una nuova istanza VCF, con il VCF Installer.
  • Update, remediate, rotate. Update imposta la password che decidi tu, remediate riallinea SDDC Manager a una password già cambiata sul componente, rotate la fa generare al sistema.
  • Auto-renewal a 60 giorni, e non su tutto. Copre solo i componenti che supportano un aggiornamento non disruptivo, e i certificati root non si rinnovano affatto.
  • ESA o OSA non cambia il verdetto. Gli stretched cluster vSAN non sono importabili in nessuna delle due architetture. E aggiornare il solo SDDC Manager non cambia la versione del management domain.