In VMware vSphere Foundation 9.0 l’identità non abita un posto solo, e le licenze non si assegnano più dove le cercavi fino alla 8.x. Il perimetro di VVF è vSphere (vCenter Standard, ESX, vSphere Supervisor), vSAN, VCF Operations e VCF Operations for Logs: niente NSX, niente VCF Automation, niente workload domain. Ne segue che gli inventari da governare sono due — quello vSphere sotto vCenter e quello di VCF Operations — con due modelli RBAC distinti, e che la licenza è un oggetto unico che si appoggia a VCF Operations.

vCenter Single Sign-On: broker di autenticazione, non database di utenti

La documentazione definisce vCenter Single Sign-On «an authentication broker and security token exchange infrastructure»: quando un utente si autentica, SSO emette un token che l’utente spende verso i servizi vCenter. I pezzi sono quattro: Security Token Service (STS), Administration server, vCenter Lookup Service e VMware Directory Service (vmdir), che gestisce anche i certificati. Il dominio predefinito è vsphere.local, e gli utenti che vedi nella scheda Users del vSphere Client sono interni a SSO e appartengono a quel dominio: non sono utenti di dominio aziendale, e sono gli unici che puoi creare localmente.

Le fonti d’identità supportate sono Active Directory over LDAP e OpenLDAP (2.4 e successivi); un aggiornamento di sicurezza Microsoft impone LDAPS per cifratura e autenticazione forte verso AD. Si aggiungono da Administration > Single Sign On > Configuration, scheda Identity Provider > Identity Sources. Lì si sceglie anche il dominio predefinito con Set as Default: uno solo alla volta, marcato «(default)» nella colonna Type. La conseguenza pratica è quella che l’help desk incontra ogni giorno: chi appartiene al dominio predefinito entra con il solo nome utente, tutti gli altri devono scrivere MYDOMAIN\user1 oppure user@mydomain.com, e chi appartiene a un dominio non configurato come identity source non entra affatto.

Le politiche di SSO — password policy (formato e scadenza), lockout policy (dopo quanti tentativi errati si blocca l’account) e token policy (clock tolerance, renewal count) — valgono solo per gli account locali del dominio vsphere.local. Se il tuo AD ha già una password policy, non la stai duplicando qui: stai regolando gli account di emergenza.

Federazione con un identity provider esterno

Dalla 9.0 la documentazione è esplicita: la federazione con un identity provider esterno è il metodo di autenticazione preferito per vCenter, che si sta muovendo verso l’autenticazione basata su token. Gli IdP supportati sono AD FS (da vSphere 7.0), Okta (da 8.0 Update 1), Microsoft Entra ID (da 8.0 Update 2) e PingFederate (da 8.0 Update 3). Quando la federazione è attiva, l’istanza dell’IdP esterno sostituisce vCenter come identity provider: è l’IdP a gestire l’interazione con l’utente. vCenter però «continues to have local accounts, for administrative access and error recovery» — ed è esattamente il motivo per cui non devi perdere la password di administrator@vsphere.local: quando l’IdP è irraggiungibile, quello è l’unico modo per rientrare.

A livello di piattaforma esiste un secondo strato, il VCF Identity Broker, che federa l’accesso ai componenti della fleet (VCF Operations, VCF Operations for Logs). Si distribuisce in due modelli: embedded nel vCenter del dominio di gestione, oppure come appliance autonoma in cluster a tre nodi, capace di servire fino a cinque istanze VCF. Parla SAML 2.0 e OpenID Connect (OIDC), si integra con Okta, Ping Identity, Microsoft Entra ID, AD FS e generici IdP SAML 2.0, oltre a AD/LDAP e OpenLDAP come directory; il provisioning di utenti e gruppi avviene via SCIM 2.0, JIT o sincronizzazione AD/LDAP.

RBAC in vSphere: permesso = utente/gruppo + ruolo + oggetto

Il modello è quello classico e va saputo a memoria nella sua forma esatta: i privilegi sono controlli d’accesso a grana fine, i ruoli sono insiemi di privilegi, il permesso associa un utente o un gruppo a un ruolo su un oggetto dell’inventario. I ruoli di sistema sono tre e non si possono modificare né cancellare: Administrator, Read-only, No Access. I sample role (AutoUpdateUser, Resource pool administrator, Virtual machine user e altri) sono modificabili, ma la pratica raccomandata è clonarli e lavorare sul clone.

Due comportamenti fanno la differenza fra un permesso che funziona e un ticket. Primo: «Propagate to children» non è selezionato di default; se assegni un ruolo su una cartella e non spunti la casella, i figli non ereditano nulla. Secondo, le regole di precedenza: un permesso impostato direttamente su un oggetto figlio sovrascrive quello del padre; un oggetto può avere molti permessi ma uno solo per ciascun utente o gruppo; se l’utente appartiene a più gruppi con ruoli diversi sullo stesso oggetto ottiene l’unione dei privilegi, ma se esiste un permesso assegnato direttamente a quell’utente, quel permesso prevale su tutti quelli di gruppo. È il meccanismo con cui si restringe un singolo amministratore senza toccare il gruppo.

I global permission sono un’altra cosa: si applicano a un oggetto radice globale che attraversa le soluzioni e coprono oggetti globali come tag e content library. Qui la trappola è documentata: se assegni un global permission senza selezionare Propagate, gli utenti «do not have access to the objects in the hierarchy», restano con qualche funzionalità globale come la creazione di ruoli.

RBAC in VCF Operations: un secondo sistema, non un riflesso del primo

VCF Operations ha il proprio controllo d’accesso, sotto Administration > Control Panel > Access Control, con le schede User Accounts, User Groups, Roles, Scopes. Gli account sono locali oppure importati da una fonte esterna (LDAP o SSO), con sincronizzazione continua dell’appartenenza ai gruppi quando l’autosync è attivo. I ruoli predefiniti sono Administrator (tutto), PowerUser (tutto tranne user management e cluster management: è il ruolo a cui vengono mappati gli utenti vCenter), PowerUserMinusRemediation (come sopra, senza le azioni di remediation), ContentAdmin (view, report, dashboard, custom group), GeneralUser-1 … GeneralUser-4 (template inizialmente ReadOnly, da personalizzare) e ReadOnly. I ruoli vengono sincronizzati verso vCenter una sola volta, durante la registrazione. Gli scope limitano su quali oggetti il ruolo agisce: esiste di default lo scope «All Objects».

Licenze: niente più chiavi da 25 caratteri

Il modello 9.0 rompe con il passato. I file di licenza a sottoscrizione sostituiscono le chiavi da 25 caratteri, e i componenti non si licenziano più singolarmente. Si lavora in due punti: la VCF Business Services console (vcf.broadcom.com), dove risiedono le sottoscrizioni, e l’istanza VCF Operations, che è il punto di gestione locale.

Il primo passo è registrare VCF Operations, da License Management > Registration. In connected mode la registrazione avviene con un activation code e non richiede trasferimenti manuali; in disconnected mode si spostano file a mano fra l’istanza e la console, sia per la registrazione sia per gli aggiornamenti di licenza e i report d’uso. Dopo il deployment l’istanza resta in evaluation mode fino a 90 giorni. Se usi VCF Operations solo per il monitoraggio e non per le licenze, la registrazione è facoltativa: l’istanza viene licenziata automaticamente con la licenza assegnata alle istanze vCenter.

La metrica è per core fisico delle CPU degli host ESX, con un minimo di 16 core per CPU fisica: una CPU da 12 core ne consuma comunque 16. vSAN si conta in TiB. Le sottoscrizioni dello stesso prodotto, stessa unità di misura e stesso Site ID confluiscono in una default license, cioè un pool unico di capacità.

Il punto che l’esame ama: le licenze si assegnano solo alle istanze vCenter; gli altri componenti collegati, host ESX compresi, vengono licenziati automaticamente. Il percorso è License Management > Licenses, scheda Version 9+, selezione di una o più istanze nella tabella vCenter Systems, poi Assign Primary License. Le licenze non assegnabili mostrano «No» nella colonna Assignable, e a operazione riuscita compare il valore in Primary License Name. Servono il permesso Manage Licenses, un’istanza registrata, le licenze già aggiunte a VCF Operations e, lato vSphere Client, l’appartenenza al gruppo SSO LicenseService.Administrators con il privilegio Global Licenses.

Per portare le licenze dentro VCF Operations si parte dalla console: License Management > Licenses > Add to VCF Operations, si scelgono licenze e istanza, si salva; in connected mode si chiude con Update Licenses sotto Registration, in disconnected mode scaricando il file e reimportandolo con Import License File. Gli add-on richiedono che la primary license sia già assegnata: con la sottoscrizione arrivano la capacità vSAN in TiB e, secondo il tier, VMware Private AI Foundation with NVIDIA. Anche gli add-on si assegnano alle istanze vCenter e da lì si applicano alle risorse gestite — per esempio i TiB vSAN a tutti i cluster vSAN di quel vCenter.

Trappole tipiche d’esame

  • VVF non è VCF. Nessun NSX, nessuna VCF Automation, nessun workload domain: le domande che parlano di identità o licenze «di dominio» vanno riportate al perimetro vSphere + vSAN + VCF Operations. Il VCF Identity Broker esiste anche qui, ma federa i componenti presenti, non NSX.
  • Propagate to children è spento di default. Uno scenario in cui «l’utente vede la cartella ma non le VM» quasi sempre finisce lì, non in un privilegio mancante.
  • Precedenza dei permessi. Figlio batte padre; più gruppi sullo stesso oggetto danno l’unione dei privilegi; ma un permesso assegnato direttamente all’utente prevale su tutti quelli di gruppo. E un global permission senza Propagate non dà accesso all’inventario.
  • Le licenze non si assegnano agli host. Si assegnano alle istanze vCenter, che licenziano il resto; non esistono più le chiavi da 25 caratteri, e il conteggio ha il pavimento dei 16 core per CPU fisica.
  • Ruoli SSO contro ruoli VCF Operations. Administrator/Read-only/No Access sono ruoli vSphere; PowerUser, ContentAdmin e i GeneralUser-n vivono in VCF Operations. Per assegnare una licenza serve il gruppo SSO LicenseService.Administrators, non un ruolo di VCF Operations.