Share via

Gestire i certificati nei cluster di Service Fabric

  • Articolo

Questo articolo illustra gli aspetti di gestione dei certificati usati per proteggere la comunicazione nei cluster di Azure Service Fabric. Completa l'introduzione alla sicurezza del cluster di Service Fabric e all'utilità di spiegazione sull'autenticazione basata su certificati X.509 in Service Fabric.

Prerequisiti

Prima di iniziare, è necessario avere familiarità con i concetti di sicurezza fondamentali e i controlli esposti da Service Fabric per configurare la sicurezza di un cluster.

Dichiarazione di non responsabilità

Questo articolo associa aspetti teorici della gestione dei certificati con esempi pratici che riguardano le specifiche di servizi, tecnologie e così via. Poiché gran parte dei destinatari qui è Microsoft-internal, l'articolo si riferisce a servizi, tecnologie e prodotti specifici di Azure. Se alcuni dettagli specifici di Microsoft non si applicano all'utente, è possibile chiedere chiarimenti o indicazioni nella sezione dei commenti alla fine.

Definizione della gestione dei certificati

Come illustrato nell'articolo complementare X.509 Autenticazione basata su certificati nei cluster di Service Fabric, un certificato è un oggetto crittografico che essenzialmente associa una coppia di chiavi asimmetriche con attributi che descrivono l'entità rappresentata.

Tuttavia, un certificato è anche un oggetto peribile , perché la sua durata è limitata ed è soggetta a compromissione. La divulgazione accidentale o un exploit riuscito può rendere un certificato inutile dal punto di vista della sicurezza. Questa caratteristica implica la necessità di modificare i certificati in modo routine o in risposta a un evento imprevisto di sicurezza.

Un altro aspetto della gestione dei certificati, e un argomento completamente separato, è la protezione delle chiavi private o dei segreti del certificato che proteggono le identità delle entità coinvolte nell'acquisizione e nel provisioning dei certificati.

Viene descritta la gestione dei certificati come processi e procedure usati per ottenere i certificati e per trasportarli in modo sicuro e sicuro nella posizione in cui sono necessari.

Alcune operazioni di gestione, ad esempio la registrazione, l'impostazione dei criteri e i controlli di autorizzazione, non rientrano nell'ambito di questo articolo. Altre operazioni, ad esempio il provisioning, il rinnovo, la richiavi o la revoca, sono correlate solo per caso a Service Fabric. Tuttavia, l'articolo li affronta in qualche modo, perché la comprensione di queste operazioni può aiutare a proteggere correttamente il cluster.

È probabile che l'obiettivo immediato sia automatizzare la gestione dei certificati il più possibile per garantire una disponibilità ininterrotta del cluster. Poiché il processo è senza tocco dell'utente, è anche possibile offrire garanzie di sicurezza. Con i cluster di Service Fabric, questo obiettivo è raggiungibile.

Il resto dell'articolo decostruisce innanzitutto la gestione dei certificati e successivamente si concentra sull'abilitazione della registrazione automatica.

In particolare, vengono trattati gli argomenti seguenti:

  • Presupposti sulla separazione delle attribuzioni tra proprietario e piattaforma
  • La pipeline lunga dal rilascio di certificati all'utilizzo
  • Rotazione dei certificati: perché, come e quando
  • Cosa potrebbe andare storto?

L'articolo non tratta questi argomenti:

  • Protezione e gestione dei nomi di dominio
  • Registrazione nei certificati
  • Configurazione dei controlli di autorizzazione per applicare il rilascio dei certificati.

Per informazioni su questi argomenti, vedere l'autorità di registrazione (RA) del servizio pkI (Public Key Infrastructure) preferito. Se si è un lettore interno di Microsoft, è possibile contattare Sicurezza di Azure.

Ruoli ed entità coinvolti nella gestione dei certificati

L'approccio alla sicurezza in un cluster di Service Fabric è un caso di "proprietario del cluster lo dichiara, il runtime di Service Fabric lo applica". Ciò significa che quasi nessuno dei certificati, delle chiavi o di altre credenziali delle identità che partecipano al funzionamento di un cluster proviene dal servizio stesso. Sono tutti dichiarati dal proprietario del cluster. Il proprietario del cluster è anche responsabile del provisioning dei certificati nel cluster, del rinnovo in base alle esigenze e di garantire sempre la sicurezza.

In particolare, il proprietario del cluster deve assicurarsi che:

  • I certificati dichiarati nella sezione NodeType del manifesto del cluster sono disponibili in ogni nodo di tale tipo, in base alle regole di presentazione.
  • I certificati dichiarati come nel punto punto elenco precedente vengono installati con le corrispondenti chiavi private incluse.
  • I certificati dichiarati nelle regole di presentazione devono superare le regole di convalida.

Service Fabric, per la sua parte, assume le responsabilità seguenti:

  • Individuazione dei certificati corrispondenti alle dichiarazioni nella definizione del cluster
  • Concessione dell'accesso alle chiavi private corrispondenti alle entità controllate da Service Fabric in base alle esigenze
  • Convalida dei certificati in conformità rigorosa con le procedure consigliate di sicurezza stabilite e la definizione del cluster
  • Generazione di avvisi in caso di scadenza imminente di certificati o errori per eseguire i passaggi di base della convalida del certificato
  • Convalidare (in qualche modo) che gli aspetti correlati al certificato della definizione del cluster siano soddisfatti dalla configurazione sottostante degli host

Ne consegue che il carico di gestione dei certificati (come operazioni attive) rientra esclusivamente nel proprietario del cluster. Le sezioni successive offrono un'analisi più attenta di ognuna delle operazioni di gestione, inclusi i meccanismi disponibili e il relativo impatto sul cluster.

Percorso di un certificato

Verrà ora descritto rapidamente l'avanzamento di un certificato dal rilascio al consumo nel contesto di un cluster di Service Fabric:

  1. Un proprietario di dominio esegue la registrazione con l'archiviazione con ridondanza geografica di un dominio o di un soggetto a cui si vuole associare i certificati. I certificati, a loro volta, costituiscono una prova di proprietà del dominio o dell'oggetto.

  2. Il proprietario del dominio designa anche nella ra le identità dei richiedenti autorizzati, le entità che hanno diritto a richiedere la registrazione dei certificati con il dominio o l'oggetto specificato.

  3. Un richiedente autorizzato esegue quindi la registrazione in un certificato tramite un servizio di gestione dei segreti. In Azure, il servizio di gestione dei segreti preferito è Azure Key Vault, che archivia in modo sicuro e consente il recupero di segreti e certificati da parte di entità autorizzate. Key Vault rinnova e richiavi il certificato come configurato nei criteri di certificato associati. Key Vault usa Microsoft Entra ID come provider di identità.

  4. Un retriever autorizzato o un agente di provisioning recupera il certificato dall'insieme di credenziali delle chiavi, inclusa la chiave privata, e lo installa nei computer che ospitano il cluster.

  5. Il servizio Service Fabric (in esecuzione con privilegi elevati in ogni nodo) concede l'accesso al certificato alle entità di Service Fabric consentite, designate dai gruppi locali e suddivise tra ServiceFabric Amministrazione istrators e ServiceFabricAllowedUsers.

  6. Il runtime di Service Fabric accede e usa il certificato per stabilire la federazione o per eseguire l'autenticazione alle richieste in ingresso dai client autorizzati.

  7. L'agente di provisioning monitora il certificato dell'insieme di credenziali delle chiavi e, quando rileva il rinnovo, attiva il flusso di provisioning. Il proprietario del cluster aggiorna quindi la definizione del cluster, se necessario, per indicare una finalità di rollover del certificato.

  8. L'agente di provisioning o il proprietario del cluster è anche responsabile della pulizia e dell'eliminazione di certificati inutilizzati.

Ai fini di questo articolo, i primi due passaggi della sequenza precedente sono principalmente non correlati. L'unica connessione è che il nome comune del soggetto del certificato è il nome DNS dichiarato nella definizione del cluster.

Il flusso di rilascio e provisioning dei certificati è illustrato nei diagrammi seguenti:

Per i certificati dichiarati dall'identificazione personale

Diagram of provisioning certificates that are declared by thumbprint.

Per i certificati dichiarati dal nome comune del soggetto

Diagram of provisioning certificates that are declared by subject common name.

Registrazione certificati

L'argomento relativo alla registrazione dei certificati è descritto in dettaglio nella documentazione di Key Vault. Un riepilogo è incluso qui per la continuità e un riferimento più semplice.

Continuando con Azure come contesto e usando Key Vault come servizio di gestione dei segreti, un richiedente di certificati autorizzato deve avere almeno le autorizzazioni di gestione dei certificati per l'insieme di credenziali delle chiavi, concesso dal proprietario dell'insieme di credenziali delle chiavi. Il richiedente esegue quindi la registrazione in un certificato come indicato di seguito:

  • Il richiedente crea un criterio certificato in Key Vault, che specifica il dominio/oggetto del certificato, l'autorità di certificazione, il tipo di chiave e la lunghezza desiderati, l'utilizzo previsto della chiave e altro ancora. Per altre informazioni, vedere Certificati in Azure Key Vault.

  • Il richiedente crea un certificato nello stesso insieme di credenziali con i criteri specificati nel passaggio precedente. A sua volta, genera una coppia di chiavi come oggetti dell'insieme di credenziali e una richiesta di firma del certificato firmata con la chiave privata, che viene quindi inoltrata all'emittente designato per la firma.

  • Dopo l'autorità di certificazione o l'autorità di certificazione (CA), risponde con il certificato firmato, il risultato viene unito all'insieme di credenziali delle chiavi e i dati del certificato sono disponibili come segue:

    • In {vaultUri}/certificates/{name}: Certificato, inclusa la chiave pubblica e i metadati
    • In {vaultUri}/keys/{name}: chiave privata del certificato, disponibile per le operazioni di crittografia (wrapping/annullamento del wrapping, firma/verifica)
    • In {vaultUri}/secrets/{name}: certificato, inclusa la chiave privata, disponibile per il download come file PFX o PEM non protetto.

Tenere presente che un certificato nell'insieme di credenziali delle chiavi contiene un elenco cronologico di istanze di certificato che condividono un criterio. Le versioni dei certificati verranno create in base agli attributi di durata e rinnovo di questo criterio. È consigliabile che i certificati dell'insieme di credenziali non condividano soggetti o domini o nomi DNS, perché possono verificarsi interruzioni in un cluster per effettuare il provisioning di istanze di certificati da certificati di insieme di credenziali diversi, con soggetti identici ma sostanzialmente diversi, ad esempio autorità di certificazione, utilizzi delle chiavi e così via. A questo punto, esiste un certificato nell'insieme di credenziali delle chiavi, pronto per l'utilizzo. Ora esaminiamo il resto del processo.

Provisioning dei certificati

È stato menzionato un agente di provisioning, ovvero l'entità che recupera il certificato, inclusa la chiave privata, dall'insieme di credenziali delle chiavi e lo installa in ognuno degli host del cluster. Tenere presente che Service Fabric non effettua il provisioning dei certificati.

Nel contesto di questo articolo, il cluster verrà ospitato in una raccolta di macchine virtuali (VM) di Azure o set di scalabilità di macchine virtuali. In Azure è possibile effettuare il provisioning di un certificato da un insieme di credenziali a una macchina virtuale o a un set di scalabilità di macchine virtuali usando i meccanismi seguenti. Ciò presuppone, come in precedenza, che all'agente di provisioning siano state concesse autorizzazioni segrete per ottenere le autorizzazioni per l'insieme di credenziali delle chiavi dal proprietario dell'insieme di credenziali delle chiavi.

  • Ad hoc: un operatore recupera il certificato dall'insieme di credenziali delle chiavi (come PFX/PKCS #12 o PEM) e lo installa in ogni nodo.

    Il meccanismo ad hoc non è consigliato, per diversi motivi, dalla sicurezza alla disponibilità e non verrà illustrato più avanti. Per altre informazioni, vedere Domande frequenti sui set di scalabilità di macchine virtuali di Azure.

  • Come segreto del set di scalabilità di macchine virtuali durante la distribuzione: usando l'identità di prima parte per conto dell'operatore, il servizio di calcolo recupera il certificato da un insieme di credenziali abilitato per la distribuzione modello e lo installa in ogni nodo del set di scalabilità di macchine virtuali, come descritto in Domande frequenti sui set di scalabilità di macchine virtuali di Azure.

    Nota

    Questo approccio consente il provisioning solo dei segreti con controllo delle versioni.

  • Usando l'estensione della macchina virtuale di Key Vault. In questo modo è possibile effettuare il provisioning dei certificati usando dichiarazioni senza versione, con aggiornamento periodico dei certificati osservati. In questo caso, la macchina virtuale/set di scalabilità di macchine virtuali deve avere un'identità gestita, un'identità a cui è stato concesso l'accesso agli insiemi di credenziali delle chiavi che contengono i certificati osservati.

Il provisioning basato su set di scalabilità di macchine virtuali/calcolo presenta vantaggi per la sicurezza e la disponibilità, ma presenta anche restrizioni. Per impostazione predefinita, è necessario dichiarare i certificati come segreti con controllo delle versioni. Questo requisito rende il provisioning basato su VMSS/calcolo adatto solo per i cluster protetti con certificati dichiarati dall'identificazione personale.

Al contrario, il provisioning basato sull'estensione della macchina virtuale di Key Vault installa sempre la versione più recente di ogni certificato osservato. che lo rende adatto solo per i cluster protetti con certificati dichiarati dal nome comune soggetto. Per sottolineare, non usare un meccanismo di provisioning automatico (ad esempio l'estensione della macchina virtuale key vault) per i certificati dichiarati dall'istanza (ovvero tramite identificazione personale). Il rischio di perdere la disponibilità è considerevole.

Esistono altri meccanismi di provisioning, ma gli approcci indicati di seguito sono le opzioni attualmente accettate per i cluster di Azure Service Fabric.

Utilizzo e monitoraggio dei certificati

Come accennato in precedenza, il runtime di Service Fabric è responsabile dell'individuazione e dell'uso dei certificati dichiarati nella definizione del cluster. L'articolo Autenticazione basata su certificati X.509 nei cluster di Service Fabric illustra in dettaglio come Service Fabric implementa le regole di presentazione e convalida e non verrà rivisitata qui. Questo articolo esaminerà l'accesso e la concessione delle autorizzazioni, nonché il monitoraggio.

Tenere presente che i certificati in Service Fabric vengono usati per molti scopi, dall'autenticazione reciproca nel livello federativo all'autenticazione TLS (Transport Layer Security) per gli endpoint di gestione. Ciò richiede che vari componenti o servizi di sistema abbiano accesso alla chiave privata del certificato. Il runtime di Service Fabric analizza regolarmente l'archivio certificati, cercando le corrispondenze per ognuna delle regole di presentazione note.

Per ogni certificato corrispondente, la chiave privata corrispondente si trova e il relativo elenco di controllo di accesso discrezionale viene aggiornato in modo da includere le autorizzazioni (lettura ed esecuzione, in genere) concesse all'identità che le richiede.

Questo processo viene definito in modo informale ACLing. Il processo viene eseguito a cadenza di un minuto e copre anche i certificati dell'applicazione , ad esempio quelli usati per crittografare le impostazioni o come certificati endpoint. L'ACL segue le regole di presentazione, quindi è importante tenere presente che i certificati dichiarati dall'identificazione personale e che vengono aggiornati automaticamente senza l'aggiornamento della configurazione del cluster che segue non saranno accessibili.

Rotazione dei certificati

Nota

Internet Engineering Task Force (IETF) RFC 3647 definisce formalmente il rinnovo come rilascio di un certificato con gli stessi attributi del certificato che viene sostituito. L'autorità emittente, la chiave pubblica dell'oggetto e le informazioni vengono mantenute. Il re-keying è il rilascio di un certificato con una nuova coppia di chiavi, senza restrizioni per stabilire se l'autorità emittente può cambiare. Poiché la distinzione potrebbe essere importante (considerare il caso dei certificati dichiarati dal nome comune del soggetto con l'aggiunta dell'autorità di certificazione), questo articolo usa la rotazione dei termini neutrali per coprire entrambi gli scenari. Tenere presente che, quando il rinnovo viene usato in modo informale, si riferisce alla richiavi.

Come accennato in precedenza, Key Vault supporta la rotazione automatica dei certificati. Ovvero, i criteri di associazione del certificato definiscono il punto nel tempo, indipendentemente dal fatto che siano trascorsi giorni prima della scadenza o della percentuale della durata totale, quando il certificato viene ruotato nell'insieme di credenziali delle chiavi. L'agente di provisioning deve essere richiamato dopo questo punto nel tempo e prima della scadenza del certificato precedente per distribuire questo nuovo certificato a tutti i nodi del cluster.

Service Fabric assiste in questo processo generando avvisi di integrità quando la data di scadenza di un certificato, attualmente in uso nel cluster, si verifica prima di un intervallo predeterminato. Un agente di provisioning automatico, l'estensione della macchina virtuale Key Vault, configurata per osservare il certificato dell'insieme di credenziali delle chiavi, esegue periodicamente il polling dell'insieme di credenziali delle chiavi, rileva la rotazione e recupera e installa il nuovo certificato. Il provisioning eseguito tramite la funzionalità segreti VM/VMSS richiede un operatore autorizzato per aggiornare la macchina virtuale/set di scalabilità di macchine virtuali con l'URI dell'insieme di credenziali delle chiavi con versione corrispondente al nuovo certificato.

Viene ora effettuato il provisioning del certificato ruotato in tutti i nodi. A questo punto, supponendo che la rotazione applicata al certificato del cluster sia stata dichiarata dal nome comune del soggetto, esaminiamo cosa accade di seguito:

  • Per le nuove connessioni all'interno del cluster, nonché nel cluster, il runtime di Service Fabric trova e seleziona il certificato corrispondente più recente (il valore massimo della proprietà NotBefore ). Si tratta di una modifica rispetto alle versioni precedenti del runtime di Service Fabric.

  • Le connessioni esistenti vengono mantenute attive o consentite di scadere o terminare in modo naturale e un gestore interno riceverà una notifica che indica che esiste una nuova corrispondenza.

Nota

Attualmente, a partire dalla versione 7.2 CU4+, Service Fabric seleziona il certificato con il valore della proprietà NotBefore più grande (rilasciato più di recente). Prima della versione 7.2 CU4, Service Fabric ha selezionato il certificato valido con il valore NotAfter più grande (più recente in scadenza).

Ciò si traduce nelle osservazioni importanti seguenti:

  • La disponibilità del cluster o delle applicazioni ospitate ha la precedenza sulla direttiva per ruotare il certificato. Il cluster convergerà sul nuovo certificato alla fine, ma senza garanzie di intervallo. Di seguito è indicato quanto segue:

    • Potrebbe non essere immediatamente evidente a un osservatore che il certificato ruotato ha completamente sostituito il suo predecessore. L'unico modo per forzare la sostituzione immediata del certificato attualmente in uso consiste nel riavviare i computer host. Non è sufficiente riavviare i nodi di Service Fabric, perché i componenti in modalità kernel che formano connessioni di lease in un cluster non saranno interessati. Inoltre, il riavvio della macchina virtuale o del set di scalabilità di macchine virtuali potrebbe causare una perdita temporanea di disponibilità. Per i certificati dell'applicazione, è sufficiente riavviare solo le rispettive istanze dell'applicazione.

    • L'introduzione di un certificato ri-chiaveto che non soddisfa le regole di convalida può interrompere efficacemente il cluster. L'esempio più comune di questo è il caso di un'autorità di certificazione imprevista, in cui i certificati del cluster vengono dichiarati dal nome comune soggetto con l'aggiunta dell'autorità di certificazione, ma il certificato ruotato è stato emesso da un'autorità emittente nuova o non dichiarata.

Pulizia del certificato

Al momento non sono previste disposizioni in Azure per la rimozione esplicita dei certificati. Spesso è un'attività non semplice per determinare se un certificato specifico viene usato in un momento specifico. Questo è più difficile per i certificati dell'applicazione rispetto ai certificati del cluster. Service Fabric, non essendo l'agente di provisioning, non eliminerà un certificato dichiarato dall'utente in alcuna circostanza. Per i meccanismi di provisioning standard:

  • Viene effettuato il provisioning dei certificati dichiarati come segreti VM/VMSS purché venga fatto riferimento nella definizione VM/VMSS e che siano recuperabili dall'insieme di credenziali delle chiavi. L'eliminazione di un segreto o di un certificato dell'insieme di credenziali delle chiavi avrà esito negativo nelle distribuzioni successive di macchine virtuali/set di scalabilità di macchine virtuali. Analogamente, la disabilitazione di una versione privata nell'insieme di credenziali delle chiavi avrà esito negativo anche nelle distribuzioni VM/VMSS che fanno riferimento alla versione del segreto.

  • Le versioni precedenti dei certificati di cui viene effettuato il provisioning tramite l'estensione della macchina virtuale di Key Vault potrebbero essere presenti o meno in un nodo VM/VMSS. L'agente recupera e installa solo la versione corrente e non rimuove alcun certificato. Ricreare l'immagine di un nodo, che in genere si verifica ogni mese, reimposta l'archivio certificati sul contenuto dell'immagine del sistema operativo e quindi le versioni precedenti verranno rimosse in modo implicito. Si consideri, tuttavia, che il ridimensionamento di un set di scalabilità di macchine virtuali comporterà l'installazione solo della versione corrente dei certificati osservati. Non presupporre l'omogeneità dei nodi in relazione ai certificati installati.

Semplificazione della gestione: esempio di registrazione automatica

Finora, questo articolo ha descritto meccanismi e restrizioni, delineato regole e definizioni complesse e ha effettuato stime direi di interruzioni. A questo punto è possibile configurare la gestione automatica dei certificati per evitare tutti questi problemi. A questo scopo, nel contesto di un cluster di Azure Service Fabric in esecuzione in un set di scalabilità di macchine virtuali PaaS (Platform as a Service) v2, usare Key Vault per la gestione dei segreti e sfruttare le identità gestite, come indicato di seguito:

  • La convalida dei certificati viene modificata dall'aggiunta dell'identificazione personale all'oggetto e all'aggiunta dell'autorità di certificazione. Qualsiasi certificato con un soggetto specifico di un'autorità emittente specifica è ugualmente attendibile.
  • I certificati vengono registrati in e ottenuti da un archivio attendibile (Key Vault) e aggiornati da un agente (qui l'estensione della macchina virtuale key vault).
  • Il provisioning dei certificati viene modificato dalla fase di distribuzione e dalla versione (come fatto dal provider di risorse di calcolo di Azure) alla post-distribuzione usando gli URI dell'insieme di credenziali delle chiavi senza versione.
  • L'accesso all'insieme di credenziali delle chiavi viene concesso tramite identità gestite assegnate dall'utente, create e assegnate al set di scalabilità di macchine virtuali durante la distribuzione.
  • Dopo la distribuzione, l'agente (estensione macchina virtuale Key Vault) esegue il polling e aggiorna i certificati osservati in ogni nodo del set di scalabilità di macchine virtuali. La rotazione dei certificati è quindi completamente automatizzata, perché Service Fabric preleva automaticamente il certificato valido più recente.

La sequenza è completamente scriptabile e automatizzata e consente una distribuzione iniziale senza tocco dell'utente di un cluster configurato per la registrazione automatica dei certificati. Le sezioni successive forniscono passaggi dettagliati, che contengono una combinazione di cmdlet di PowerShell e frammenti di modelli JSON. La stessa funzionalità è ottenibile con tutti i mezzi supportati per interagire con Azure.

Nota

In questo esempio si presuppone che un certificato esista già nell'insieme di credenziali delle chiavi. La registrazione e il rinnovo di un certificato gestito da Key Vault richiedono passaggi manuali dei prerequisiti, come descritto in precedenza in questo articolo. Per gli ambienti di produzione, usare i certificati gestiti da Key Vault. È stato incluso uno script di esempio specifico di un'infrastruttura a chiave pubblica interna Microsoft.

Nota

La registrazione automatica dei certificati ha senso solo per i certificati rilasciati dalla CA. L'uso di certificati autofirmati, inclusi quelli generati durante la distribuzione di un cluster di Service Fabric nell'portale di Azure, non è distinzione, ma è comunque possibile per le distribuzioni locali o ospitate dallo sviluppatore se si dichiara l'identificazione personale dell'autorità di certificazione come quella del certificato foglia.

Punto di partenza

Per brevità, si presuppone lo stato iniziale seguente:

  • Il cluster di Service Fabric esiste ed è protetto con un certificato rilasciato dalla CA dichiarato dall'identificazione personale.
  • Il certificato viene archiviato in un insieme di credenziali delle chiavi ed è stato effettuato il provisioning come segreto del set di scalabilità di macchine virtuali.
  • Lo stesso certificato verrà usato per convertire il cluster in dichiarazioni di certificato comuni basate sul nome e quindi convalidarlo da soggetto ed emittente. In caso contrario, ottenere il certificato rilasciato dalla CA destinato a questo scopo e aggiungerlo alla definizione del cluster tramite identificazione personale. Questo processo è illustrato in Aggiungere o rimuovere certificati per un cluster di Service Fabric in Azure.

Ecco un estratto JSON da un modello che corrisponde a tale stato. L'estratto omette molte impostazioni necessarie e illustra solo gli aspetti correlati al certificato.

  "resources": [
    {   ## VMSS definition
      "apiVersion": "[variables('vmssApiVersion')]",
      "type": "Microsoft.Compute/virtualMachineScaleSets",
      "name": "[variables('vmNodeTypeName')]",
      "location": "[variables('computeLocation')]",
      "properties": {
        "virtualMachineProfile": {
          "extensionProfile": {
            "extensions": [
            {
                "name": "[concat('ServiceFabricNodeVmExt','_vmNodeTypeName')]",
                "properties": {
                  "type": "ServiceFabricNode",
                  "autoUpgradeMinorVersion": true,
                  "publisher": "Microsoft.Azure.ServiceFabric",
                  "settings": {
                    "clusterEndpoint": "[reference(parameters('clusterName')).clusterEndpoint]",
                    "nodeTypeRef": "[variables('vmNodeTypeName')]",
                    "dataPath": "D:\\SvcFab",
                    "durabilityLevel": "Bronze",
                    "certificate": {
                        "thumbprint": "[parameters('primaryClusterCertificateTP')]",
                        "x509StoreName": "[parameters('certificateStoreValue')]"
                    }
                  },
                  "typeHandlerVersion": "1.1"
                }
            },}},
          "osProfile": {
            "adminPassword": "[parameters('adminPassword')]",
            "adminUsername": "[parameters('adminUsername')]",
            "secrets": [
            {
                "sourceVault": {
                    "id": "[resourceId('Microsoft.KeyVault/vaults', parameters('keyVaultName'))]"
                },
                "vaultCertificates": [
                {
                    "certificateStore": "[parameters('certificateStoreValue')]",
                    "certificateUrl": "[parameters('clusterCertificateUrlValue')]"
                },
            ]}]
        },
    },
    {   ## cluster definition
        "apiVersion": "[variables('sfrpApiVersion')]",
        "type": "Microsoft.ServiceFabric/clusters",
        "name": "[parameters('clusterName')]",
        "location": "[parameters('clusterLocation')]",
        "certificate": {
            "thumbprint": "[parameters('primaryClusterCertificateTP')]",
            "x509StoreName": "[parameters('certificateStoreValue')]"
        },
    }
  ]

Il codice precedente indica essenzialmente che il certificato con identificazione json [parameters('primaryClusterCertificateTP')] personale e trovato nell'URI json [parameters('clusterCertificateUrlValue')] di Key Vault viene dichiarato come certificato unico del cluster, tramite identificazione personale.

Configurare quindi le risorse aggiuntive necessarie per garantire la registrazione automatica del certificato.

Configurare le risorse dei prerequisiti

Come accennato in precedenza, un certificato di cui viene effettuato il provisioning come segreto del set di scalabilità di macchine virtuali viene recuperato dall'insieme di credenziali delle chiavi dal servizio Provider di risorse di calcolo Microsoft. A tale scopo, usa l'identità di prima parte per conto dell'operatore di distribuzione. Questo processo cambierà per la registrazione automatica. Si passerà all'uso di un'identità gestita assegnata al set di scalabilità di macchine virtuali e a cui sono state concesse le autorizzazioni GET per i segreti in tale insieme di credenziali.

È consigliabile distribuire contemporaneamente gli estratti successivi. Vengono elencati singolarmente solo per l'analisi e la spiegazione di play-by-play.

Prima di tutto, definire un'identità assegnata dall'utente (i valori predefiniti sono inclusi come esempi). Per altre informazioni, vedere la documentazione ufficiale.

{
  "$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "parameters": {
    "userAssignedIdentityName": {
      "type": "string",
      "defaultValue": "sftstuaicus",
      "metadata": {
        "description": "User-assigned managed identity name"
      }
    },
  },
  "variables": {
      "vmssApiVersion": "2018-06-01",
      "sfrpApiVersion": "2018-02-01",
      "miApiVersion": "2018-11-30",
      "kvApiVersion": "2018-02-14",
      "userAssignedIdentityResourceId": "[resourceId('Microsoft.ManagedIdentity/userAssignedIdentities', parameters('userAssignedIdentityName'))]"
  },    
  "resources": [
    {
      "type": "Microsoft.ManagedIdentity/userAssignedIdentities",
      "name": "[parameters('userAssignedIdentityName')]",
      "apiVersion": "[variables('miApiVersion')]",
      "location": "[resourceGroup().location]"
    },
  ]}

Concedere quindi a questa identità l'accesso ai segreti dell'insieme di credenziali delle chiavi. Per informazioni più aggiornate, vedere la documentazione ufficiale.

  "resources":
  [{
      "type": "Microsoft.KeyVault/vaults/accessPolicies",
      "name": "[concat(parameters('keyVaultName'), '/add')]",
      "apiVersion": "[variables('kvApiVersion')]",
      "properties": {
        "accessPolicies": [
          {
            "tenantId": "[reference(variables('userAssignedIdentityResourceId'), variables('miApiVersion')).tenantId]",
            "objectId": "[reference(variables('userAssignedIdentityResourceId'), variables('miApiVersion')).principalId]",
            "dependsOn": [
              "[variables('userAssignedIdentityResourceId')]"
            ],
            "permissions": {
              "secrets": [
                "get",
                "list"
              ]}}]}}]

Nel passaggio successivo si eseguiranno le operazioni seguenti:

  • Assegnare l'identità assegnata dall'utente al set di scalabilità di macchine virtuali.
  • Dichiarare la dipendenza del set di scalabilità di macchine virtuali dalla creazione dell'identità gestita e dal risultato della concessione dell'accesso all'insieme di credenziali delle chiavi.
  • Dichiarare l'estensione della macchina virtuale di Key Vault e richiederla per recuperare i certificati osservati all'avvio. Per altre informazioni, vedere la documentazione ufficiale dell'estensione vm di Key Vault per Windows .
  • Aggiornare la definizione dell'estensione della macchina virtuale di Service Fabric in modo da dipendere dall'estensione della macchina virtuale di Key Vault e convertire la dichiarazione del certificato del cluster dall'identificazione personale al nome comune.

Nota

Queste modifiche vengono apportate come singolo passaggio perché rientrano nell'ambito della stessa risorsa.

  "parameters": {
    "kvvmextPollingInterval": {
      "type": "string",
      "defaultValue": "3600",
      "metadata": {
        "description": "kv vm extension polling interval in seconds"
      }
    },
    "kvvmextLocalStoreName": {
      "type": "string",
      "defaultValue": "MY",
      "metadata": {
        "description": "kv vm extension local store name"
      }
    },
    "kvvmextLocalStoreLocation": {
      "type": "string",
      "defaultValue": "LocalMachine",
      "metadata": {
        "description": "kv vm extension local store location"
      }
    },
    "kvvmextObservedCertificates": {
      "type": "array",
      "defaultValue": [
                "https://sftestcus.vault.azure.net/secrets/sftstcncluster",
                "https://sftestcus.vault.azure.net/secrets/sftstcnserver"
            ],
      "metadata": {
        "description": "kv vm extension observed certificates versionless uri"
      }
    },
    "certificateCommonName": {
      "type": "string",
      "defaultValue": "cus.cluster.sftstcn.system.servicefabric.azure-int",
      "metadata": {
        "description": "Certificate Common name"
      }
    },
  },
  "resources": [
  {
    "apiVersion": "[variables('vmssApiVersion')]",
    "type": "Microsoft.Compute/virtualMachineScaleSets",
    "name": "[variables('vmNodeTypeName')]",
    "location": "[variables('computeLocation')]",
    "dependsOn": [
      "[variables('userAssignedIdentityResourceId')]",
      "[concat('Microsoft.KeyVault/vaults/', concat(parameters('keyVaultName'), '/accessPolicies/add'))]"
    ],
    "identity": {
      "type": "UserAssigned",
      "userAssignedIdentities": {
        "[variables('userAssignedIdentityResourceId')]": {}
      }
    },
    "virtualMachineProfile": {
      "extensionProfile": {
        "extensions": [
        {
          "name": "KVVMExtension",
          "properties": {
            "publisher": "Microsoft.Azure.KeyVault",
            "type": "KeyVaultForWindows",
            "typeHandlerVersion": "1.0",
            "autoUpgradeMinorVersion": true,
            "settings": {
                "secretsManagementSettings": {
                    "pollingIntervalInS": "[parameters('kvvmextPollingInterval')]",
                    "linkOnRenewal": false,
                    "observedCertificates": "[parameters('kvvmextObservedCertificates')]",
                    "requireInitialSync": true
                }
            }
          }
        },
        {
        "name": "[concat('ServiceFabricNodeVmExt','_vmNodeTypeName')]",
        "properties": {
          "type": "ServiceFabricNode",
          "provisionAfterExtensions" : [ "KVVMExtension" ],
          "publisher": "Microsoft.Azure.ServiceFabric",
          "settings": {
            "certificate": {
                "commonNames": [
                    "[parameters('certificateCommonName')]"
                ],
                "x509StoreName": "[parameters('certificateStoreValue')]"
            }
            },
            "typeHandlerVersion": "1.0"
          }
        },
  ] } ## extension profile
  },  ## VM profile
  "osProfile": {
    "adminPassword": "[parameters('adminPassword')]",
    "adminUsername": "[parameters('adminUsername')]",
  } 
  }
  ]

Anche se non è elencato in modo esplicito nel codice precedente, si noti che l'URL del certificato dell'insieme di credenziali delle chiavi è stato rimosso dalla OsProfile sezione del set di scalabilità di macchine virtuali.

Il passaggio finale consiste nell'aggiornare la definizione del cluster per modificare la dichiarazione del certificato dall'identificazione personale al nome comune. Vengono aggiunte anche le identificazioni personali dell'autorità di certificazione:

  "parameters": {
    "certificateCommonName": {
      "type": "string",
      "defaultValue": "cus.cluster.sftstcn.system.servicefabric.azure-int",
      "metadata": {
        "description": "Certificate Common name"
      }
    },
    "certificateIssuerThumbprint": {
      "type": "string",
      "defaultValue": "1b45ec255e0668375043ed5fe78a09ff1655844d,d7fe717b5ff3593764f4d90654d86e8362ec26c8,3ac7c3cac8de0dd392c02789c8be97474f456960,96ea05926e2e42cc207e358668be2c316857fb5e",
      "metadata": {
        "description": "Certificate issuer thumbprints separated by comma"
      }
    },
  },
  "resources": [
    {
      "apiVersion": "[variables('sfrpApiVersion')]",
      "type": "Microsoft.ServiceFabric/clusters",
      "name": "[parameters('clusterName')]",
      "location": "[parameters('clusterLocation')]",
      "properties": {
        "certificateCommonNames": {
          "commonNames": [{
              "certificateCommonName": "[parameters('certificateCommonName')]",
              "certificateIssuerThumbprint": "[parameters('certificateIssuerThumbprint')]"
          }],
          "x509StoreName": "[parameters('certificateStoreValue')]"
        },
  ]

A questo punto, è possibile eseguire gli aggiornamenti indicati in precedenza in una singola distribuzione. Per la sua parte, il servizio provider di risorse di Service Fabric suddivide l'aggiornamento del cluster in diversi passaggi, come descritto nel segmento per convertire i certificati del cluster dall'identificazione personale al nome comune.

Analisi e osservazioni

In questa sezione vengono illustrati i concetti e i processi presentati in questo articolo, oltre a attirare l'attenzione su alcuni altri aspetti importanti.

Informazioni sul provisioning dei certificati

L'estensione della macchina virtuale di Key Vault, come agente di provisioning, viene eseguita continuamente in base a una frequenza predeterminata. Se non riesce a recuperare un certificato osservato, continua con la riga successiva e quindi si iberna fino al ciclo successivo. L'estensione macchina virtuale di Service Fabric, come agente di avvio automatico del cluster, richiede i certificati dichiarati prima che il cluster possa formare. In questo modo, a sua volta, l'estensione della macchina virtuale di Service Fabric può essere eseguita solo dopo il recupero corretto dei certificati del cluster, indicato qui dalla json "provisionAfterExtensions" : [ "KVVMExtension" ]" clausola e dall'impostazione dell'estensione della json "requireInitialSync": true macchina virtuale di Key Vault.

Ciò indica all'estensione della macchina virtuale di Key Vault che, al primo esecuzione (dopo la distribuzione o un riavvio), deve scorrere i certificati osservati fino a quando non vengono scaricati tutti correttamente. Se si imposta questo parametro su false, associato a un errore di recupero dei certificati del cluster, si verifica un errore nella distribuzione del cluster. Al contrario, la richiesta di una sincronizzazione iniziale con un elenco non corretto o non valido di certificati osservati provocherebbe un errore dell'estensione della macchina virtuale di Key Vault e, di nuovo, un errore di distribuzione del cluster.

Collegamento dei certificati, illustrato

È possibile che sia stato notato il flag di estensione linkOnRenewal della macchina virtuale di Key Vault e il fatto che sia impostato su false. Questa impostazione risolve il comportamento controllato da questo flag e le relative implicazioni sul funzionamento di un cluster. Questo comportamento è specifico di Windows.

In base alla definizione:

"linkOnRenewal": <Only Windows. This feature enables auto-rotation of SSL certificates, without necessitating a re-deployment or binding. e.g.: false>,

I certificati usati per stabilire una connessione TLS vengono normalmente acquisiti come handle tramite il provider di supporto per la sicurezza S-channel. Ovvero, il client non accede direttamente alla chiave privata del certificato stesso. Il canale S supporta il reindirizzamento o il collegamento di credenziali sotto forma di estensione del certificato CERT_RENEWAL_PROP_ID.

Se questa proprietà è impostata, il relativo valore rappresenta l'identificazione personale del certificato di rinnovo e quindi S-channel tenterà invece di caricare il certificato collegato. Infatti, il canale S attraversa questo collegato e, speriamo, elenco aciclico fino a quando non finisce con il certificato finale , uno senza un contrassegno di rinnovo. Questa funzionalità, se usata con cautela, è un'ottima mitigazione contro una perdita di disponibilità causata, ad esempio, dai certificati scaduti.

In altri casi, può essere la causa di interruzioni che sono difficili da diagnosticare e attenuare. Il canale S esegue l'attraversamento dei certificati sulle proprietà di rinnovo in modo incondizionato, indipendentemente da soggetto, autorità emittenti o altri attributi specifici che partecipano alla convalida del certificato risultante dal client. È possibile che il certificato risultante non abbia una chiave privata associata o che la chiave non sia stata associata al consumer potenziale.

Se il collegamento è abilitato, l'estensione della macchina virtuale key vault, quando recupera un certificato osservato dall'insieme di credenziali delle chiavi, tenterà di trovare la corrispondenza, i certificati esistenti per collegarli tramite la proprietà dell'estensione per il rinnovo. La corrispondenza si basa esclusivamente sul nome alternativo del soggetto (SAN) e funziona, se sono presenti due certificati esistenti, come illustrato negli esempi seguenti: A: Nome certificato (CN) = "Accessori di Alice", SAN = {"alice.universalexports.com"}, renewal = '' B: CN = "Bob's bits", SAN = {"bob.universalexports.com", "bob.universalexports.net"}, renewal = ''

Si supponga che un certificato C venga recuperato dall'estensione della macchina virtuale di Key Vault: CN = "Malware di Mallory", SAN = {"alice.universalexports.com", "bob.universalexports.com", "mallory.universalexports.com"}

L'elenco SAN del certificato A è completamente incluso in C e quindi A.renewal = C.thumbprint. L'elenco san del certificato B ha un'intersezione comune con C, ma non è inclusa completamente, quindi B.renewal rimane vuoto.

Qualsiasi tentativo di richiamare AcquireCredentialsHandle (S-channel) in questo stato nel certificato A termina effettivamente l'invio di C alla parte remota. Nel caso di Service Fabric, il sottosistema trasporto di un cluster usa S-channel per l'autenticazione reciproca e quindi il comportamento descritto in precedenza influisce direttamente sulla comunicazione fondamentale del cluster. Continuando con l'esempio precedente e presupponendo che A sia il certificato del cluster, l'operazione successiva dipende da:

  • Se la chiave privata di C non è ACL nell'account in cui è in esecuzione Service Fabric, si noteranno errori per acquisire la chiave privata (edizione StandardC_E_UNKNOWN_CREDENTIALS o simile).
  • Se la chiave privata di C è accessibile, verranno visualizzati errori di autorizzazione restituiti dagli altri nodi (CertificateNotMatched, non autorizzato e così via).

In entrambi i casi, il trasporto ha esito negativo e il cluster potrebbe andare inattivo. I sintomi variano. Per peggiorare le cose, il collegamento dipende dall'ordine di rinnovo, determinato dall'ordine dell'elenco dei certificati osservati dell'estensione della macchina virtuale di Key Vault, dalla pianificazione del rinnovo nell'insieme di credenziali delle chiavi o anche da errori temporanei che alterano l'ordine di recupero.

Per attenuare tali eventi imprevisti, è consigliabile:

  • Non combinare i nomi alternativi del soggetto di certificati dell'insieme di credenziali diversi. Ogni certificato dell'insieme di credenziali deve soddisfare uno scopo distinto e il relativo soggetto e SAN devono riflettere tale condizione con specificità.

  • Includere il nome comune dell'oggetto nell'elenco SAN (come, letteralmente, CN=<subject common name>).

  • Se non si è certi di come procedere, disabilitare il collegamento al rinnovo per i certificati di cui è stato effettuato il provisioning con l'estensione della macchina virtuale di Key Vault.

    Nota

    La disabilitazione del collegamento è una proprietà di primo livello dell'estensione della macchina virtuale dell'insieme di credenziali delle chiavi e non può essere impostata per i singoli certificati osservati.

Perché è consigliabile usare un'identità gestita assegnata dall'utente? Quali sono le implicazioni dell'uso?

Poiché è diventato evidente dai frammenti JSON precedenti, è necessaria una sequenziazione specifica delle operazioni e degli aggiornamenti per garantire il successo della conversione e mantenere la disponibilità del cluster. In particolare, la risorsa del set di scalabilità di macchine virtuali dichiara e usa la propria identità per recuperare i segreti in un singolo aggiornamento (dal punto di vista dell'utente).

L'estensione della macchina virtuale di Service Fabric, che esegue il bootstrap del cluster, dipende dal completamento dell'estensione della macchina virtuale dell'insieme di credenziali delle chiavi, che a sua volta dipende dal recupero corretto dei certificati osservati.

L'estensione della macchina virtuale Key Vault usa l'identità del set di scalabilità di macchine virtuali per accedere all'insieme di credenziali delle chiavi, il che significa che i criteri di accesso nell'insieme di credenziali delle chiavi devono essere già stati aggiornati prima della distribuzione del set di scalabilità di macchine virtuali.

Per eliminare la creazione di un'identità gestita o assegnarla a un'altra risorsa, l'operatore di distribuzione deve avere il ruolo necessario (ManagedIdentityOperator) nella sottoscrizione o nel gruppo di risorse, oltre ai ruoli necessari per gestire le altre risorse a cui si fa riferimento nel modello.

Dal punto di vista della sicurezza, tenere presente che il set di scalabilità di macchine virtuali è considerato un limite di sicurezza per quanto riguarda l'identità di Azure. Ciò significa che qualsiasi applicazione ospitata nella macchina virtuale potrebbe, in linea di principio, ottenere un token di accesso che rappresenta la macchina virtuale. I token di accesso all'identità gestita vengono ottenuti dall'endpoint del servizio metadati dell'istanza non autenticato. Se si considera che la macchina virtuale sia un ambiente condiviso o multi-tenant, questo metodo di recupero dei certificati cluster potrebbe non essere indicato. È tuttavia l'unico meccanismo di provisioning adatto per la registrazione automatica dei certificati.

Risoluzione dei problemi e domande frequenti

D: Come è possibile eseguire la registrazione a livello di codice in un certificato gestito da Key Vault?

Individuare il nome dell'emittente dalla documentazione di Key Vault e sostituirlo nello script seguente:

  $issuerName=<depends on your PKI of choice>
	$clusterVault="sftestcus"
	$clusterCertVaultName="sftstcncluster"
	$clusterCertCN="cus.cluster.sftstcn.system.servicefabric.azure-int"
	Set-AzKeyVaultCertificateIssuer -VaultName $clusterVault -Name $issuerName -IssuerProvider $issuerName
	$distinguishedName="CN=" + $clusterCertCN
	$policy = New-AzKeyVaultCertificatePolicy `
	    -IssuerName $issuerName `
	    -SubjectName $distinguishedName `
	    -SecretContentType 'application/x-pkcs12' `
	    -Ekus "1.3.6.1.5.5.7.3.1", "1.3.6.1.5.5.7.3.2" `
	    -ValidityInMonths 4 `
	    -KeyType 'RSA' `
	    -RenewAtPercentageLifetime 75        
	Add-AzKeyVaultCertificate -VaultName $clusterVault -Name $clusterCertVaultName -CertificatePolicy $policy
	
	# poll the result of the enrollment
	Get-AzKeyVaultCertificateOperation -VaultName $clusterVault -Name $clusterCertVaultName

D: Cosa accade quando un certificato viene emesso da un'autorità emittente non dichiarata o non specificata? Dove è possibile ottenere un elenco completo di autorità emittenti attive di un'infrastruttura a chiave pubblica specifica?

Se la dichiarazione del certificato specifica le identificazioni personali dell'autorità di certificazione e l'autorità emittente diretta del certificato non è inclusa nell'elenco di autorità emittenti aggiunte, il certificato verrà considerato non valido, indipendentemente dal fatto che la radice sia considerata attendibile dal client. Pertanto, è fondamentale assicurarsi che l'elenco di emittenti sia aggiornato. L'introduzione di un nuovo emittente è un evento raro e dovrebbe essere ampiamente pubblicizzata prima di iniziare a rilasciare certificati.

In generale, un'infrastruttura a chiave pubblica e gestisce un'istruzione pratica di certificazione, in conformità con IETF RFC 7382. Oltre ad altre informazioni, l'istruzione include tutte le autorità emittenti attive. Il recupero di questo elenco a livello di codice potrebbe differire da un'infrastruttura a chiave pubblica a un'altra.

Per le infrastruttura a chiave pubblica interna microsoft, consultare la documentazione interna sugli endpoint e sugli SDK usati per recuperare le autorità di certificazione autorizzate. È responsabilità del proprietario del cluster esaminare periodicamente questo elenco per assicurarsi che la definizione del cluster includa tutte le autorità emittenti previste.

D: Sono supportate più pki?

Sì. Non è possibile dichiarare più voci CN nel manifesto del cluster con lo stesso valore, ma è possibile elencare le autorità di certificazione da più PKI che corrispondono allo stesso cn. Non è una procedura consigliata e le procedure di trasparenza dei certificati potrebbero impedire l'emissione di tali certificati. Tuttavia, come mezzo per eseguire la migrazione da un'infrastruttura a chiave pubblica (PKI) a un'altra, si tratta di un meccanismo accettabile.

D: Cosa accade se il certificato del cluster corrente non è rilasciato dalla CA o non ha l'oggetto previsto?

Ottenere un certificato con l'oggetto desiderato e aggiungerlo alla definizione del cluster come secondario, tramite identificazione personale. Al termine dell'aggiornamento, avviare un altro aggiornamento della configurazione del cluster per convertire la dichiarazione del certificato in nome comune.