In VCF 9.0 identità e licenze hanno smesso di essere due argomenti separati: si configurano entrambi dalla console di VCF Operations, che in questa versione è il punto di governo della fleet. Chi arriva da VCF 5.x deve disimparare due riflessi: l’identità non si configura più prodotto per prodotto, e le licenze non sono più chiavi da incollare.

Chi entra in VCF Single Sign-On e chi resta fuori

VCF Single Sign-On dà un’unica sorgente di autenticazione a vCenter, NSX, VCF Operations, VCF Automation, VCF Operations for Logs, VCF Operations for Networks, VCF Operations Orchestrator e VCF Operations HCX. Restano fuori dal flusso unificato SDDC Manager ed ESX: la UI di SDDC Manager accetta solo account locali, tipicamente utenti @vsphere.local, mentre le sue API accettano anche utenti SSO. È una asimmetria che va ricordata, perché è esattamente il genere di dettaglio che l’esame trasforma in distrattore.

Due vincoli pesanti prima di iniziare. L’Enhanced Linked Mode va disattivato su tutti i vCenter che parteciperanno, e le configurazioni di identity provider già presenti sui vCenter vengono sovrascritte. Inoltre utenti e gruppi non migrano da soli: dopo l’abilitazione vanno riprovisionati e ri-mappati sui ruoli di servizio di ogni componente. Il logout, infine, è per singolo componente: uscire da uno non chiude le sessioni degli altri.

Embedded o appliance: la scelta del VCF Identity Broker

Il motore è il VCF Identity Broker, in due modalità. In embedded vive nel vCenter del management domain dell’istanza VCF: richiede vCenter 9.0 o superiore con licenza VMware Cloud Foundation e nessun ELM attivo, ed è la strada più semplice, ma se il vCenter non è raggiungibile l’autenticazione cade con lui. In appliance è un cluster a tre nodi distribuito tramite il fleet management di VCF Operations, tollera la perdita di un nodo, resta accessibile anche senza vCenter e può servire fino a cinque istanze VCF.

La modalità ha una conseguenza pratica poco intuitiva: le automazioni PowerCLI continuano a funzionare in embedded, mentre in appliance vanno riconfigurate. L’installazione dell’appliance passa da Fleet Management Lifecycle, dove si scarica il binario e si sceglie Add sull’identity broker, poi New Install (o Import, per un ripristino), e si compilano nell’ordine Infrastructure, Network e Components — password, certificati, FQDN, VIP del cluster e pool IP dei nodi — prima di precheck e submit.

Identity provider, client e reset

Il percorso è VCF Operations → Fleet Management → Identity & Access, con l’istanza scelta dal menu VCF Instances. Il flusso guidato ha sette passi: selezione dell’istanza, scelta del deployment mode, configurazione dell’identity provider, aggancio di NSX e vCenter, aggancio di VCF Operations e VCF Automation, aggancio facoltativo degli altri componenti, assegnazione di ruoli e permessi. I protocolli sono SAML 2.0, OpenID Connect e AD/LDAP (incluso OpenLDAP), con provider come Okta, Ping Identity, Microsoft Entra ID e ADFS; il provisioning di utenti e gruppi avviene via SCIM 2.0, JIT o AD/LDAP.

Una seconda istanza VCF non riparte da zero: dalla pagina Enable Single Sign-On si sceglie Connect to an existing SSO configuration, si seleziona il broker dal menu Identity Broker, si spuntano i componenti nella pagina Configure clients e si conferma il dialogo Role Assignment Required.

Per cambiare identity provider si va nella scheda Identity Source e si usa Reset SSO, scegliendo l’opzione che cancella solo la configurazione dell’IdP con utenti e gruppi provisionati: deployment mode e client restano intatti. Per cambiare invece la modalità di deployment serve l’opzione che cancella tutto, IdP, utenti, gruppi e configurazioni dei client, e poi si riparte dalla schermata Enable Single Sign-On.

RBAC in VCF Operations e in VCF Automation

L’access control di VCF Operations sta in Administration → Control Panel → Access Control, con le schede User Accounts, User Groups, Roles e Scopes. I ruoli predefiniti sono Administrator, PowerUser (tutto tranne user management e cluster management, ed è quello assegnato automaticamente agli utenti vCenter), PowerUserMinusRemediation, ContentAdmin, GeneralUser-1…4 (nascono ReadOnly e sono personalizzabili) e ReadOnly. Il ruolo dice cosa si può fare, lo scope dice su quali oggetti: lo scope predefinito All Objects apre tutto, ed è anche il requisito per chi configura l’SSO. I gruppi importati da LDAP restano sincronizzati in continuo. Per verificare l’assetto esistono i report User Activity Audit, User Permissions Audit, System Audit e System Component Audit.

VCF Automation ha un RBAC proprio, a due livelli: Organization Administrator, Organization User e Organization Auditor sull’organizzazione; Project Administrator, Project Advanced User, Project User e Project Auditor sul progetto, assegnati da Manage & Govern → Projects, scheda Users, con Add Users o Add Groups. Gli identity provider dell’organizzazione (LDAP, SAML, OIDC) li configura solo l’organization administrator.

Licenze: subscription, registrazione, assegnazione

Le chiavi non esistono più. Si acquista una subscription a termine con una capacità, e ne nasce una default license che è il pool di capacità di tutte le subscription attive dello stesso prodotto nello stesso Site ID. Nella VCF Business Services console (vcf.broadcom.com) quella default license si può splittare in quante licenze servono entro la capacità acquistata, modificarne la capacità e cancellarle: la capacità di una licenza splittata cancellata rientra nella default. Le licenze primarie sono VMware Cloud Foundation e VMware vSphere Foundation; le add-on sono vSAN (TiB) e VMware Private AI Foundation with NVIDIA (core).

VCF Operations va registrato con la console: dopo il deploy o l’upgrade lavora in evaluation mode fino a 90 giorni, e serve che l’adapter VIM sia in esecuzione. La registrazione connected usa un codice di attivazione e invia l’uso da sola; la disconnected richiede scambio manuale di file. Si commuta da License Management → Registration con Switch to Disconnected o Switch to Connected; se si è rimasti disconnessi oltre 180 giorni la commutazione può fallire e serve un nuovo codice. Le licenze vanno comunque aggiornate almeno ogni 180 giorni, e — differenza rispetto alle versioni precedenti — l’aggiornamento non obbliga a riassegnarle agli asset.

Le licenze si aggiungono dalla console con License Management → Licenses → Add to VCF Operations, poi si completano da VCF Operations con Update Licenses (connected) o Import License File (disconnected). L’assegnazione avviene nella scheda Version 9+, tabella vCenter Systems: si selezionano uno o più vCenter e si usa Assign Primary License o Assign Add-on License, con esito nelle colonne Primary License Name e Add-on License Name. Servono il permesso Manage Licenses, il vCenter integrato con VCF Operations (può volerci qualche ciclo di raccolta prima che compaia) e, lato vSphere Client, l’appartenenza al gruppo LicenseService.Administrators. Il license sharing consente di condividere licenze fra tenant o di darne il controllo a un provider, ed è appannaggio di Tenant Administrator o License Manager.

Trappole tipiche d’esame

  • VCF non è VVF. Il VCF Identity Broker non è disponibile in VMware vSphere Foundation: lì si usa il servizio embedded nel vCenter. Uno scenario che chiede un broker appliance in un ambiente VVF sta chiedendo una cosa impossibile.
  • SDDC Manager ed ESX sono fuori dall’SSO, e dentro SDDC Manager la UI accetta solo account locali mentre le API accettano utenti SSO: la risposta «tutti i componenti VCF» è quasi sempre sbagliata.
  • Enhanced Linked Mode e VCF SSO non convivono. Se lo scenario descrive vCenter in ELM, il primo passo non è configurare l’IdP: è smontare l’ELM.
  • I due Reset SSO non sono lo stesso reset. Cambiare identity provider conserva deployment mode e client; cambiare deployment mode cancella anche quelli. Distinguere quale opzione produce quale perdita è una domanda perfetta da scenario.
  • Le licenze si assegnano ai vCenter, non a host o cluster, e nessuna add-on si assegna prima di una primaria. Attenzione anche ai due orologi diversi: 90 giorni di evaluation dopo il deploy, 180 giorni fra un aggiornamento licenze e il successivo.