Dela via

Hantera certifikat i Service Fabric-kluster

  • Artikel

Den här artikeln beskriver hanteringsaspekterna av certifikat som används för att skydda kommunikationen i Azure Service Fabric-kluster. Den kompletterar introduktionen till Service Fabric-klustersäkerhet och förklaringen för X.509-certifikatbaserad autentisering i Service Fabric.

Förutsättningar

Innan du börjar bör du känna till grundläggande säkerhetsbegrepp och de kontroller som Service Fabric exponerar för att konfigurera säkerheten för ett kluster.

Friskrivning

Den här artikeln kombinerar teoretiska aspekter av certifikathantering med praktiska exempel som täcker detaljerna för tjänster, tekniker och så vidare. Eftersom en stor del av målgruppen här är Microsoft-intern refererar artikeln till tjänster, tekniker och produkter som är specifika för Azure. Om viss Microsoft-specifik information inte gäller för dig kan du be om förtydligande eller vägledning i kommentarsavsnittet i slutet.

Definiera certifikathantering

Som du lär dig i den tillhörande artikeln X.509 Certifikatbaserad autentisering i Service Fabric-kluster är ett certifikat ett kryptografiskt objekt som i princip binder ett asymmetriskt nyckelpar med attribut som beskriver den entitet som det representerar.

Ett certifikat är dock också ett lättfördärvligt objekt eftersom dess livslängd är begränsad och kan komprometteras. Oavsiktligt avslöjande eller en lyckad exploatering kan göra ett certifikat oanvändbart ur säkerhetssynpunkt. Den här egenskapen innebär att du måste ändra certifikaten antingen rutinmässigt eller som svar på en säkerhetsincident.

En annan aspekt av certifikathantering, och ett helt separat ämne, är skyddet av privata certifikatnycklar eller hemligheter som skyddar identiteterna för de entiteter som ingår i inköp och etablering av certifikat.

Vi beskriver certifikathantering som de processer och procedurer som används för att hämta certifikat och för att transportera dem på ett säkert och säkert sätt dit de behövs.

Vissa hanteringsåtgärder, till exempel registrering, principinställning och auktoriseringskontroller, ligger utanför den här artikelns omfång. Andra åtgärder, till exempel etablering, förnyelse, omnyckelläggning eller återkallning, är endast relaterade för övrigt till Service Fabric. Artikeln löser dem dock något, eftersom du kan skydda klustret på rätt sätt genom att förstå dessa åtgärder.

Ditt omedelbara mål är troligen att automatisera certifikathanteringen så mycket som möjligt för att säkerställa klustrets oavbrutna tillgänglighet. Eftersom processen är användarlös vill du också erbjuda säkerhetsgarantier. Med Service Fabric-kluster kan det här målet uppnås.

Resten av artikeln dekonstruerar först certifikathantering och fokuserar senare på att aktivera automatisk registrering.

Mer specifikt beskrivs följande avsnitt:

  • Antaganden om uppdelning av attribut mellan ägare och plattform
  • Den långa pipelinen från certifikatutfärdande till förbrukning
  • Certifikatrotation: Varför, hur och när
  • Vad kan gå fel?

Artikeln beskriver inte följande ämnen:

  • Skydda och hantera domännamn
  • Registrera i certifikat
  • Konfigurera auktoriseringskontroller för att framtvinga certifikatutfärdande.

Information om dessa ämnen finns i registreringsutfärdarna (RA) för din favorittjänst för offentlig nyckelinfrastruktur (PKI). Om du är en Microsoft-intern läsare kan du kontakta Azure Security.

Roller och entiteter som ingår i certifikathantering

Säkerhetsmetoden i ett Service Fabric-kluster handlar om "klusterägaren deklarerar det, Service Fabric-körningen framtvingar det". Det innebär att nästan inget av certifikaten, nycklarna eller andra autentiseringsuppgifter för identiteter som deltar i ett klusters funktion kommer från själva tjänsten. Alla deklareras av klusterägaren. Klusterägaren ansvarar också för att etablera certifikaten i klustret, förnya dem efter behov och säkerställa deras säkerhet hela tiden.

Mer specifikt måste klusterägaren se till att:

  • Certifikat som deklareras i avsnittet NodeType i klustermanifestet finns på varje nod av den typen, enligt presentationsreglerna.
  • Certifikat som deklareras som i föregående punkt installeras med motsvarande privata nycklar inkluderade.
  • Certifikat som deklareras i presentationsreglerna bör godkännas av verifieringsreglerna.

Service Fabric å sin sida tar på sig följande ansvarsområden:

  • Hitta certifikat som matchar deklarationerna i klusterdefinitionen
  • Bevilja åtkomst till motsvarande privata nycklar till Service Fabric-kontrollerade entiteter på behovsbasis
  • Verifiera certifikat i strikt enlighet med etablerade rekommenderade säkerhetsmetoder och klusterdefinitionen
  • Skapa aviseringar om förestående förfallodatum för certifikat eller om det inte går att utföra de grundläggande stegen i certifikatverifieringen
  • Verifierar (till viss del) att certifikatrelaterade aspekter av klusterdefinitionen uppfylls av den underliggande konfigurationen av värdarna

Härav följer att certifikathanteringsbördan (som aktiva åtgärder) endast faller på klusterägaren. Nästa avsnitt ger en närmare titt på var och en av hanteringsåtgärderna, inklusive tillgängliga mekanismer och deras inverkan på klustret.

Resan för ett certifikat

Nu ska vi snabbt beskriva utvecklingen av ett certifikat från utfärdande till förbrukning i kontexten för ett Service Fabric-kluster:

  1. En domänägare registrerar sig med RA för en PKI en domän eller ett ämne som de vill associera med efterföljande certifikat. Certifikaten utgör i sin tur bevis på ägarskap för domänen eller ämnet.

  2. Domänägaren anger också i RA identiteterna för behöriga begäranden, entiteter som har rätt att begära registrering av certifikat med den angivna domänen eller ämnet.

  3. En auktoriserad beställare registrerar sig sedan i ett certifikat via en tjänst för hemlig hantering. I Azure är den hemliga hanteringstjänsten Azure Key Vault, som på ett säkert sätt lagrar och tillåter hämtning av hemligheter och certifikat av auktoriserade entiteter. Key Vault förnyar och återställer även certifikatet enligt konfigurationen i den associerade certifikatprincipen. Key Vault använder Microsoft Entra-ID som identitetsprovider.

  4. En auktoriserad retriever eller etableringsagent hämtar certifikatet från nyckelvalvet, inklusive dess privata nyckel, och installerar det på datorerna som är värdar för klustret.

  5. Service Fabric-tjänsten (körs förhöjd på varje nod) ger åtkomst till certifikatet till de tillåtna Service Fabric-entiteterna, som utses av lokala grupper och delas mellan ServiceFabricAdministrators och ServiceFabricAllowedUsers.

  6. Service Fabric-körningen kommer åt och använder certifikatet för att upprätta federation eller för att autentisera till inkommande begäranden från auktoriserade klienter.

  7. Etableringsagenten övervakar nyckelvalvscertifikatet och utlöser etableringsflödet när förnyelse identifieras. Klusterägaren uppdaterar sedan klusterdefinitionen om det behövs för att ange en avsikt att rulla över certifikatet.

  8. Etableringsagenten eller klusterägaren ansvarar också för att rensa och ta bort oanvända certifikat.

I den här artikeln är de två första stegen i föregående sekvens mestadels orelaterade. Deras enda anslutning är att certifikatets ämnesnamn är det DNS-namn som deklareras i klusterdefinitionen.

Certifikatutfärdande och etableringsflöde visas i följande diagram:

För certifikat som deklareras med tumavtryck

Diagram över etableringscertifikat som deklareras med tumavtryck.

För certifikat som deklareras med ämnesnamnet

Diagram över etableringscertifikat som deklareras med ämnesnamn.

Certifikatregistrering

Ämnet för certifikatregistrering beskrivs i detalj i Key Vault-dokumentationen. En synopsis ingår här för kontinuitet och enklare referens.

Om du fortsätter med Azure som kontext och använder Key Vault som hemlighetshanteringstjänst måste en auktoriserad certifikatförfråganare ha minst certifikathanteringsbehörigheter för nyckelvalvet, som beviljats av nyckelvalvets ägare. Beställaren registrerar sig sedan i ett certifikat på följande sätt:

  • Beställaren skapar en certifikatprincip i Key Vault, som anger certifikatets domän/ämne, önskad utfärdare, nyckeltyp och längd, avsedd nyckelanvändning med mera. Mer information finns i Certifikat i Azure Key Vault.

  • Beställaren skapar ett certifikat i samma valv med principen som anges i föregående steg. Detta genererar i sin tur ett nyckelpar som valvobjekt och en begäran om certifikatsignering som är signerad med den privata nyckeln, som sedan vidarebefordras till den utsedda utfärdaren för signering.

  • När utfärdaren eller certifikatutfärdaren svarar med det signerade certifikatet sammanfogas resultatet till nyckelvalvet och certifikatdata är tillgängliga på följande sätt:

    • Under {vaultUri}/certificates/{name}: Certifikatet, inklusive den offentliga nyckeln och metadata
    • Under {vaultUri}/keys/{name}: Certifikatets privata nyckel, tillgänglig för kryptografiska åtgärder (wrap/unwrap, sign/verify)
    • Under {vaultUri}/secrets/{name}: Certifikatet, inklusive dess privata nyckel, är tillgängligt för nedladdning som en oskyddad PFX- eller PEM-fil.

Kom ihåg att ett certifikat i nyckelvalvet innehåller en kronologisk lista över certifikatinstanser som delar en princip. Certifikatversioner skapas enligt livslängds- och förnyelseattributen för den här principen. Vi rekommenderar starkt att valvcertifikat inte delar ämnen eller domäner eller DNS-namn, eftersom det kan vara störande i ett kluster att etablera certifikatinstanser från olika valvcertifikat, med identiska ämnen men väsentligt olika andra attribut, till exempel utfärdare, nyckelanvändningar och så vidare. Nu finns ett certifikat i nyckelvalvet, redo för förbrukning. Nu ska vi utforska resten av processen.

Certifikatetablering

Vi nämnde en etableringsagent, som är entiteten som hämtar certifikatet, inklusive dess privata nyckel, från nyckelvalvet och installerar det på var och en av värdarna i klustret. (Kom ihåg att Service Fabric inte etablerar certifikat.)

I den här artikeln kommer klustret att finnas på en samling virtuella Azure-datorer (VM) eller VM-skalningsuppsättningar. I Azure kan du etablera ett certifikat från ett valv till en virtuell dator/VMSS med hjälp av följande mekanismer. Detta förutsätter, precis som tidigare, att etableringsagenten tidigare har beviljats hemliga behörigheter för nyckelvalvet av nyckelvalvets ägare.

  • Ad hoc: En operatör hämtar certifikatet från nyckelvalvet (som PFX/PKCS #12 eller PEM) och installerar det på varje nod.

    Ad hoc-mekanismen rekommenderas inte av flera skäl, allt från säkerhet till tillgänglighet, och den diskuteras inte här ytterligare. Mer information finns i Vanliga frågor och svar om skalningsuppsättningar för virtuella Azure-datorer.

  • Som en hemlighet för vm-skalningsuppsättningar under distributionen: Genom att använda sin identitet från första part åt operatören hämtar beräkningstjänsten certifikatet från ett malldistributionsaktiverat valv och installerar det på varje nod i vm-skalningsuppsättningen, enligt beskrivningen i Vanliga frågor och svar om skalningsuppsättningar för virtuella Azure-datorer.

    Kommentar

    Den här metoden tillåter endast etablering av versionshemligheter.

  • Med hjälp av tillägget för den virtuella Key Vault-datorn. På så sätt kan du etablera certifikat med hjälp av versionslösa deklarationer, med regelbunden uppdatering av observerade certifikat. I det här fallet förväntas den virtuella datorn/VMSS ha en hanterad identitet, en identitet som har beviljats åtkomst till de nyckelvalv som innehåller de observerade certifikaten.

VMSS/beräkningsbaserad etablering medför säkerhets- och tillgänglighetsfördelar, men det medför även begränsningar. Det kräver, avsiktligt, att du deklarerar certifikat som versionshemligheter. Det här kravet gör VMSS/beräkningsbaserad etablering lämplig endast för kluster som skyddas med certifikat som deklareras med tumavtryck.

Key Vault VM-tilläggsbaserad etablering installerar däremot alltid den senaste versionen av varje observerat certifikat. vilket gör den endast lämplig för kluster som skyddas med certifikat som deklareras med ämnesnamnet. För att betona bör du inte använda en mekanism för automatisk återutfärdande av etablering (till exempel tillägget för den virtuella Key Vault-datorn) för certifikat som deklareras per instans (dvs. med tumavtryck). Risken att förlora tillgängligheten är betydande.

Det finns andra etableringsmekanismer, men de metoder som nämns här är de för närvarande godkända alternativen för Azure Service Fabric-kluster.

Förbrukning och övervakning av certifikat

Som tidigare nämnts ansvarar Service Fabric-körningen för att hitta och använda certifikaten som deklareras i klusterdefinitionen. I artikeln X.509 Certificate-based authentication in Service Fabric clusters (X.509-certifikatbaserad autentisering i Service Fabric-kluster) beskrivs i detalj hur Service Fabric implementerar presentations- och valideringsreglerna, och det kommer inte att ses över här. Den här artikeln kommer att titta på beviljande av åtkomst och behörighet samt övervakning.

Kom ihåg att certifikat i Service Fabric används för en mängd olika syften, från ömsesidig autentisering i federationsskiktet till TLS-autentisering (Transport Layer Security) för hanteringsslutpunkterna. Detta kräver att olika komponenter eller systemtjänster har åtkomst till certifikatets privata nyckel. Service Fabric-körningen söker regelbundet igenom certifikatarkivet och letar efter matchningar för var och en av de kända presentationsreglerna.

För varje matchande certifikat finns motsvarande privata nyckel och dess lista över diskretionära åtkomstkontroll uppdateras så att den innehåller behörigheter (läs och kör vanligtvis) som beviljas till den identitet som kräver dem.

Den här processen kallas informellt för ACLing. Processen körs på en minuts takt och omfattar även programcertifikat , till exempel de som används för att kryptera inställningar eller som slutpunktscertifikat. ACLing följer presentationsreglerna, så det är viktigt att komma ihåg att certifikat som deklareras med tumavtryck och som uppdateras automatiskt utan den efterföljande klusterkonfigurationsuppdateringen är otillgängliga.

Certifikatrotation

Kommentar

IETF (Internet Engineering Task Force) RFC 3647 definierar formellt förnyelse som utfärdande av ett certifikat med samma attribut som det certifikat som ersätts. Utfärdaren, ämnets offentliga nyckel och informationen bevaras. Omnyckeln är utfärdandet av ett certifikat med ett nytt nyckelpar, utan begränsningar för om utfärdaren kan ändras. Eftersom skillnaden kan vara viktig (tänk på fallet med certifikat som deklareras efter ämnesnamn med utfärdarens fästning), använder den här artikeln neutral termrotation för att täcka båda scenarierna. Tänk på att när förnyelse används informellt refererar det till omnyckelläggning.

Som tidigare nämnts har Key Vault stöd för automatisk certifikatrotation. Den associerade certifikatprincipen definierar alltså tidpunkten, oavsett om det är dagar före förfallodatum eller procentandel av den totala livslängden, när certifikatet roteras i nyckelvalvet. Etableringsagenten måste anropas efter den här tidpunkten och innan det nu tidigare certifikatet upphör att gälla för att distribuera det nya certifikatet till alla noder i klustret.

Service Fabric hjälper till i den här processen genom att höja hälsovarningar när förfallodatumet för ett certifikat, som för närvarande används i klustret, inträffar tidigare än ett förutbestämt intervall. En automatisk etableringsagent, Key Vault VM-tillägget, som är konfigurerat för att observera nyckelvalvscertifikatet, avsöker regelbundet nyckelvalvet, identifierar rotationen och hämtar och installerar det nya certifikatet. Etablering som sker via funktionen VM/VMSS-hemligheter kräver att en auktoriserad operatör uppdaterar den virtuella datorn/VMSS med den versionshanterade Key Vault-URI:n som motsvarar det nya certifikatet.

Det roterade certifikatet etableras nu till alla noder. Anta nu att rotationen som tillämpas på klustercertifikatet har deklarerats med ämnesnamnet gemensamt, nu ska vi undersöka vad som händer härnäst:

  • För nya anslutningar i klustret hittar och väljer Service Fabric-körningen det senast utfärdade matchande certifikatet (det största värdet för egenskapen NotBefore ). Det här är en ändring från tidigare versioner av Service Fabric-körningen.

  • Befintliga anslutningar hålls vid liv eller tillåts att upphöra att gälla naturligt eller på annat sätt avslutas, och en intern hanterare har fått ett meddelande om att det finns en ny matchning.

Kommentar

Från och med version 7.2 CU4+ väljer Service Fabric för närvarande certifikatet med det största (senast utfärdade) NotBefore-egenskapsvärdet . Före 7.2 CU4 valde Service Fabric det giltiga certifikatet med det största (senaste utgångna) NotAfter-värdet .

Detta innebär följande viktiga observationer:

  • Tillgängligheten för klustret eller värdbaserade program har företräde framför direktivet för att rotera certifikatet. Klustret konvergerar på det nya certifikatet så småningom, men utan tidsgarantier. Här följer följande:

    • Det kanske inte är omedelbart uppenbart för en övervakare att det roterade certifikatet helt ersatte sin föregångare. Det enda sättet att framtvinga omedelbar ersättning av det certifikat som för närvarande används är att starta om värddatorerna. Det räcker inte att starta om Service Fabric-noderna eftersom komponenterna i kernelläget som bildar låneanslutningar i ett kluster inte påverkas. Dessutom kan omstart av den virtuella datorn/VMSS orsaka tillfällig förlust av tillgänglighet. För programcertifikat räcker det att bara starta om respektive programinstanser.

    • Om du introducerar ett omnyckelat certifikat som inte uppfyller verifieringsreglerna kan klustret effektivt brytas. Det vanligaste exemplet på detta är fallet med en oväntad utfärdare, där klustercertifikaten deklareras efter ämnesnamn med utfärdarens fästning, men det roterade certifikatet utfärdades av en ny eller odeklarerad utfärdare.

Rensning av certifikat

För närvarande finns det inga bestämmelser i Azure för explicit borttagning av certifikat. Det är ofta en icke-trivial uppgift att avgöra om ett specifikt certifikat används vid en viss tidpunkt. Det här är svårare för programcertifikat än för klustercertifikat. Själva Service Fabric, som inte är etableringsagenten, tar inte bort ett certifikat som deklareras av användaren under några omständigheter. För standardetableringsmekanismerna:

  • Certifikat som deklareras som VM/VMSS-hemligheter etableras så länge de refereras till i DEFINITIONEN VM/VMSS och kan hämtas från nyckelvalvet. Om du tar bort en nyckelvalvshemlighet eller ett certifikat misslyckas efterföljande VM/VMSS-distributioner. Om du inaktiverar en hemlig version i nyckelvalvet misslyckas även VM/VMSS-distributioner som refererar till den hemliga versionen.

  • Tidigare versioner av certifikat som etableras via Key Vault VM-tillägget kanske eller kanske inte finns på en VM/VMSS-nod. Agenten hämtar och installerar endast den aktuella versionen och tar inte bort några certifikat. Ombilda en nod, som vanligtvis inträffar varje månad, återställer certifikatarkivet till innehållet i OS-avbildningen och därför tas tidigare versioner implicit bort. Tänk dock på att skalning av en VM-skalningsuppsättning endast resulterar i att den aktuella versionen av observerade certifikat installeras. Anta inte att noderna är homogena när det gäller installerade certifikat.

Förenklad hantering: Ett exempel på automatisk registrering

Hittills har den här artikeln beskrivit mekanismer och begränsningar, beskrivit invecklade regler och definitioner och gjort svåra förutsägelser om avbrott. Nu är det dags att konfigurera automatisk certifikathantering för att undvika alla dessa problem. Låt oss göra det i kontexten för ett Azure Service Fabric-kluster som körs på en paaS v2-skalningsuppsättning (plattform som en tjänst) med hjälp av Key Vault för hantering av hemligheter och användning av hanterade identiteter på följande sätt:

  • Validering av certifikat ändras från tumavtrycks-fästning till ämne + utfärdar-fästning. Alla certifikat med ett specifikt ämne från en specifik utfärdare är lika betrodda.
  • Certifikat registreras i och hämtas från ett betrott arkiv (Key Vault) och uppdateras av en agent (här tillägget för den virtuella Key Vault-datorn).
  • Etablering av certifikat ändras från distributionstid och versionsbaserad (enligt Azure Compute Resource Provider) till efterdistribution med hjälp av versionslösa Key Vault-URI:er.
  • Åtkomst till nyckelvalvet beviljas via användartilldelade hanterade identiteter, som skapas och tilldelas till vm-skalningsuppsättningen under distributionen.
  • Efter distributionen avsöker agenten (Key Vault VM-tillägget) och uppdaterar observerade certifikat på varje nod i vm-skalningsuppsättningen. Certifikatrotationen är därför helt automatiserad eftersom Service Fabric automatiskt hämtar det senaste giltiga certifikatet.

Sekvensen är helt skriptbar och automatiserad och tillåter en användarlös inledande distribution av ett kluster som är konfigurerat för automatisk registrering av certifikat. Nästa avsnitt innehåller detaljerade steg som innehåller en blandning av PowerShell-cmdletar och fragment av JSON-mallar. Samma funktioner kan uppnås med alla metoder som stöds för att interagera med Azure.

Kommentar

Det här exemplet förutsätter att ett certifikat redan finns i ditt nyckelvalv. Registrering och förnyelse av ett Key Vault-hanterat certifikat kräver nödvändiga manuella steg, enligt beskrivningen tidigare i den här artikeln. För produktionsmiljöer använder du Key Vault-hanterade certifikat. Vi har inkluderat ett exempelskript som är specifikt för en Microsoft-intern PKI.

Kommentar

Automatisk registrering av certifikat är endast meningsfullt för CERTIFIKATutfärdade certifikat. Att använda självsignerade certifikat, inklusive de som genereras under distributionen av ett Service Fabric-kluster i Azure-portalen, är meningslöst, men fortfarande möjligt för lokala distributioner eller distributioner med utvecklare om du deklarerar att utfärdarens tumavtryck är detsamma som för lövcertifikatet.

Utgångspunkt

För korthet antar vi följande starttillstånd:

  • Service Fabric-klustret finns och skyddas med ett CA-utfärdat certifikat som deklareras med tumavtryck.
  • Certifikatet lagras i ett nyckelvalv och etableras som en hemlighet för vm-skalningsuppsättningar.
  • Samma certifikat används för att konvertera klustret till vanliga namnbaserade certifikatdeklarationer, så att det kan verifieras av ämne och utfärdare. Om så inte är fallet hämtar du certifikatutfärdat CERTIFIKAT som är avsett för det här ändamålet och lägger till det i klusterdefinitionen med tumavtryck. Den här processen förklaras i Lägg till eller ta bort certifikat för ett Service Fabric-kluster i Azure.

Här är ett JSON-utdrag från en mall som motsvarar ett sådant tillstånd. Utdraget utelämnar många obligatoriska inställningar och illustrerar endast de certifikatrelaterade aspekterna.

  "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')]"
        },
    }
  ]

Föregående kod säger i princip att certifikatet med tumavtryck json [parameters('primaryClusterCertificateTP')] och som finns på Key Vault URI json [parameters('clusterCertificateUrlValue')] deklareras som klustrets enda certifikat, med tumavtryck.

Nu ska vi konfigurera de ytterligare resurser som behövs för att säkerställa automatisk registrering av certifikatet.

Konfigurera nödvändiga resurser

Som tidigare nämnts hämtas ett certifikat som etableras som en hemlighet för vm-skalningsuppsättningar från nyckelvalvet av Microsoft Compute Resource Provider-tjänsten. Det gör den med hjälp av sin identitet från första part för distributionsoperatorns räkning. Den processen ändras för automatisk registrering. Du växlar till att använda en hanterad identitet som har tilldelats vm-skalningsuppsättningen och som har beviljats GET-behörighet för hemligheterna i valvet.

Du bör distribuera nästa utdrag samtidigt. De listas endast individuellt för spelanalys och förklaring.

Definiera först en användartilldelad identitet (standardvärden ingår som exempel). Mer information finns i den officiella dokumentationen.

{
  "$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]"
    },
  ]}

Ge sedan den här identiteten åtkomst till key vault-hemligheterna. Den senaste informationen finns i den officiella dokumentationen.

  "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"
              ]}}]}}]

I nästa steg gör du följande:

  • Tilldela den användartilldelade identiteten till vm-skalningsuppsättningen.
  • Deklarera vm-skalningsuppsättningens beroende av skapandet av den hanterade identiteten och på resultatet av att ge den åtkomst till nyckelvalvet.
  • Deklarera tillägget för den virtuella Key Vault-datorn och kräva att det hämtar observerade certifikat vid start. Mer information finns i den officiella dokumentationen för Key Vault VM-tillägget för Windows .
  • Uppdatera definitionen av Service Fabric VM-tillägget så att det är beroende av tillägget för den virtuella Key Vault-datorn och konvertera klustercertifikatdeklarationen från tumavtryck till eget namn.

Kommentar

Dessa ändringar görs som ett enda steg eftersom de omfattas av samma resursomfång.

  "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')]",
  } 
  }
  ]

Även om det inte uttryckligen anges i föregående kod bör du tänka på att url:en för nyckelvalvets certifikat har tagits bort från OsProfile avsnittet i vm-skalningsuppsättningen.

Det sista steget är att uppdatera klusterdefinitionen för att ändra certifikatdeklarationen från tumavtryck till gemensamt namn. Vi fäster även utfärdarens tumavtryck:

  "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')]"
        },
  ]

Nu kan du köra de tidigare nämnda uppdateringarna i en enda distribution. Service Fabric Resource Provider-tjänsten delar å sin sida upp klusteruppgraderingen i flera steg, enligt beskrivningen i segmentet om att konvertera klustercertifikat från tumavtryck till eget namn.

Analys och observationer

Det här avsnittet är en catch-all för att förklara begrepp och processer som har presenterats i hela den här artikeln, samt uppmärksamma vissa andra viktiga aspekter.

Om certifikatetablering

Key Vault VM-tillägget, som en etableringsagent, körs kontinuerligt på en fördefinierad frekvens. Om det inte går att hämta ett observerat certifikat fortsätter det till nästa rad och viloläge till nästa cykel. Service Fabric VM-tillägget, som klusterstövlaragenten, kräver de deklarerade certifikaten innan klustret kan bildas. Detta innebär i sin tur att service fabric VM-tillägget endast kan köras efter att klustercertifikaten har hämtats, som anges här av json "provisionAfterExtensions" : [ "KVVMExtension" ]" -satsen, och med key vault VM-tilläggets json "requireInitialSync": true inställning.

Detta anger för tillägget för den virtuella Key Vault-datorn att det vid den första körningen (efter distributionen eller omstarten) måste gå igenom sina observerade certifikat tills alla har laddats ned. Om den här parametern anges till false, tillsammans med ett fel vid hämtning av klustercertifikaten, skulle det leda till ett fel i klusterdistributionen. Om du däremot kräver en inledande synkronisering med en felaktig eller ogiltig lista över observerade certifikat skulle det leda till ett fel i tillägget för den virtuella Key Vault-datorn och, återigen, ett fel vid distributionen av klustret.

Certifikatlänkning, förklaras

Du kanske har lagt märke till key vault VM-tilläggsflaggan linkOnRenewal och det faktum att den är inställd på false. Den här inställningen tar upp det beteende som styrs av den här flaggan och dess konsekvenser för hur ett kluster fungerar. Det här beteendet är specifikt för Windows.

Enligt dess definition:

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

Certifikat som används för att upprätta en TLS-anslutning hämtas vanligtvis som handtag via S-kanalens säkerhetssupportleverantör. Det innebär att klienten inte har direkt åtkomst till den privata nyckeln för själva certifikatet. S-kanalen stöder omdirigering eller länkning av autentiseringsuppgifter i form av ett certifikattillägg, CERT_RENEWAL_PROP_ID.

Om den här egenskapen anges representerar dess värde tumavtrycket för förnyelsecertifikatet , så S-kanalen försöker i stället läsa in det länkade certifikatet. I själva verket kommer S-kanalen att passera den länkade och förhoppningsvis acykliska listan tills den slutar med det slutliga certifikatet, ett utan förnyelsemärke. Den här funktionen, när den används på ett omdömesgillt sätt, är en bra åtgärd mot en förlust av tillgänglighet som orsakas av till exempel utgångna certifikat.

I andra fall kan det vara orsaken till avbrott som är svåra att diagnostisera och minimera. S-kanalen kör bläddring av certifikat på sina förnyelseegenskaper villkorslöst, oavsett ämne, utfärdare eller andra specifika attribut som deltar i valideringen av det resulterande certifikatet av klienten. Det är möjligt att det resulterande certifikatet inte har någon associerad privat nyckel eller att nyckeln inte har kopplats till den potentiella konsumenten.

Om länkning är aktiverat försöker key vault VM-tillägget, när det hämtar ett observerat certifikat från nyckelvalvet, hitta matchande befintliga certifikat för att länka dem via egenskapen för förnyelsetillägget. Matchningen baseras uteslutande på det alternativa namnet på certifikatmottagaren (SAN) och fungerar, om det finns två befintliga certifikat, som visas i följande exempel: A: Certifikatnamn (CN) = "Alices tillbehör", SAN = {"alice.universalexports.com"}, förnyelse = '' B: CN = "Bobs bitar", SAN = {"bob.universalexports.com", "bob.universalexports.net"}, förnyelse = ''

Anta att ett certifikat C hämtas av key vault VM-tillägget: CN = "Mallory's malware", SAN = {"alice.universalexports.com", "bob.universalexports.com", "mallory.universalexports.com"}

Certifikat A:s SAN-lista ingår helt i C:er, så A.renewal = C.thumbprint. Certifikat B:s SAN-lista har en gemensam skärningspunkt med C: er, men ingår inte helt i den, så B.renewal förblir tom.

Alla försök att anropa AcquireCredentialsHandle (S-kanal) i det här tillståndet på certifikat A skickar faktiskt C till fjärrparten. När det gäller Service Fabric använder undersystemet Transport i ett kluster S-kanal för ömsesidig autentisering, och därför påverkar det tidigare beskrivna beteendet klustrets grundläggande kommunikation direkt. Om du fortsätter med föregående exempel och antar att A är klustercertifikatet beror vad som händer härnäst på:

  • Om C:s privata nyckel inte är acLed till det konto som Service Fabric körs som, ser du fel när du hämtar den privata nyckeln (SEC_E_UNKNOWN_CREDENTIALS eller liknande).
  • Om C:s privata nyckel är tillgänglig visas auktoriseringsfel som returneras av de andra noderna (CertificateNotMatched, obehörig och så vidare).

I båda fallen misslyckas transporten och klustret kan gå ned. Symptomen varierar. För att göra saken värre beror länken på förnyelseordningen, vilket bestäms av ordningen på listan över observerade certifikat för tillägget för den virtuella Key Vault-datorn, förnyelseschemat i nyckelvalvet eller till och med tillfälliga fel som skulle ändra ordningen på hämtningen.

För att undvika sådana incidenter rekommenderar vi följande:

  • Blanda inte de alternativa ämnesnamnen för olika valvcertifikat. Varje valvcertifikat bör ha ett distinkt syfte, och dess ämne och SAN bör återspegla det med specificitet.

  • Inkludera ämnets gemensamma namn i SAN-listan (som, bokstavligen, CN=<subject common name>).

  • Om du är osäker på hur du ska gå vidare inaktiverar du länkning vid förnyelse för certifikat som har etablerats med tillägget för den virtuella Key Vault-datorn.

    Kommentar

    Att inaktivera länkning är en toppnivåegenskap för key vault VM-tillägget och kan inte anges för enskilda observerade certifikat.

Varför ska jag använda en användartilldelad hanterad identitet? Vilka är konsekvenserna av att använda den?

Eftersom det framgår av föregående JSON-kodfragment krävs en specifik sekvensering av åtgärderna och uppdateringarna för att både garantera att konverteringen lyckas och upprätthålla klustrets tillgänglighet. Mer specifikt deklarerar och använder den virtuella datorns skalningsuppsättningsresurs sin identitet för att hämta hemligheter i en enskild uppdatering (från användarens perspektiv).

Service Fabric VM-tillägget, som startar klustret, beror på slutförandet av tillägget för den virtuella Key Vault-datorn, vilket i sin tur beror på att observerade certifikat har hämtats.

Key Vault VM-tillägget använder vm-skalningsuppsättningens identitet för att komma åt nyckelvalvet, vilket innebär att åtkomstprincipen för nyckelvalvet redan måste ha uppdaterats innan vm-skalningsuppsättningen distribueras.

Om du vill ta bort skapandet av en hanterad identitet eller tilldela den till en annan resurs måste distributionsoperatorn ha den roll som krävs (ManagedIdentityOperator) i prenumerationen eller resursgruppen, utöver de roller som krävs för att hantera de andra resurser som refereras i mallen.

Ur säkerhetssynpunkt bör du komma ihåg att vm-skalningsuppsättningen betraktas som en säkerhetsgräns när det gäller dess Azure-identitet. Det innebär att alla program som finns på den virtuella datorn i princip kan hämta en åtkomsttoken som representerar den virtuella datorn. Åtkomsttoken för hanterad identitet hämtas från slutpunkten för tjänsten för oautentiserade instansmetadata. Om du anser att den virtuella datorn är en delad miljö eller en miljö med flera klientorganisationer kanske den här metoden för att hämta klustercertifikat inte anges. Det är dock den enda etableringsmekanismen som lämpar sig för automatisk registrering av certifikat.

Felsökning och vanliga frågor och svar

F: Hur kan jag registrera mig programmatiskt i ett Key Vault-hanterat certifikat?

Ta reda på namnet på utfärdaren från Key Vault-dokumentationen och ersätt det sedan i följande skript:

  $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

F: Vad händer när ett certifikat utfärdas av en odeklarerad eller ospecificerad utfärdare? Var kan jag få en fullständig lista över aktiva utfärdare av en specifik PKI?

Om certifikatdeklarationen anger tumavtryck för utfärdaren och den direkta utfärdaren av certifikatet inte ingår i listan över fästa utfärdare anses certifikatet vara ogiltigt, oavsett om dess rot är betrodd av klienten eller inte. Därför är det viktigt att se till att listan över utfärdare är aktuell. Introduktionen av en ny utfärdare är en sällsynt händelse, och den bör offentliggöras i stor utsträckning innan den börjar utfärda certifikat.

I allmänhet publicerar och underhåller en PKI en certifieringspraxis i enlighet med IETF RFC 7382. Förutom annan information innehåller -instruktionen alla aktiva utfärdare. Om du hämtar den här listan programmatiskt kan det skilja sig från en PKI till en annan.

För Microsoft-interna PKIs bör du läsa den interna dokumentationen om de slutpunkter och SDK:er som används för att hämta auktoriserade utfärdare. Det är klusterägarens ansvar att regelbundet granska den här listan för att säkerställa att klusterdefinitionen innehåller alla förväntade utfärdare.

F: Stöds flera PKIs?

Ja. Du kanske inte deklarerar flera CN-poster i klustermanifestet med samma värde, men du kan lista utfärdare från flera PKIs som motsvarar samma CN. Det är inte en rekommenderad metod, och metoder för certifikattransparens kan förhindra att sådana certifikat utfärdas. Men som ett sätt att migrera från en PKI till en annan är detta en acceptabel mekanism.

F: Vad händer om det aktuella klustercertifikatet inte har utfärdats av certifikatutfärdare eller inte har det avsedda ämnet?

Hämta ett certifikat med det avsedda ämnet och lägg till det i klustrets definition som sekundärt, med tumavtryck. När uppgraderingen har slutförts initierar du en annan klusterkonfigurationsuppgradering för att konvertera certifikatdeklarationen till ett gemensamt namn.