Správa certifikátů v clusterech Service Fabric

Tento článek se zabývá aspekty správy certifikátů, které se používají k zabezpečení komunikace v clusterech Azure Service Fabric. Doplňuje úvod do zabezpečení clusteru Service Fabric a vysvětlení ověřování na základě certifikátů X.509 v Service Fabric.

Předpoklady

Než začnete, měli byste být obeznámeni se základními koncepty zabezpečení a ovládacími prvky, které Service Fabric zpřístupňuje ke konfiguraci zabezpečení clusteru.

Právní doložka

Tento článek spáruje teoretické aspekty správy certifikátů s praktických příklady, které pokrývají specifika služeb, technologií atd. Vzhledem k tomu, že velká část této cílové skupiny je interní, článek se týká služeb, technologií a produktů specifických pro Azure. Pokud se na vás některé podrobnosti specifické pro Microsoft nevztahují, můžete požádat o objasnění nebo pokyny v části s komentáři na konci.

Definování správy certifikátů

Jak se dozvíte v doprovodné článku X.509 Ověřování na základě certifikátů v clusterech Service Fabric, certifikát je kryptografický objekt, který v podstatě sváže asymetrický pár klíčů s atributy, které popisují entitu, kterou představuje.

Certifikát je ale také objekt, který je možné poškodit , protože jeho životnost je omezená a je náchylná k ohrožení zabezpečení. Náhodné zveřejnění nebo úspěšné zneužití může způsobit, že certifikát bude z hlediska zabezpečení nepoužitelný. Tato charakteristika znamená potřebu měnit certifikáty buď rutinně, nebo v reakci na incident zabezpečení.

Dalším aspektem správy certifikátů a zcela samostatným tématem je ochrana privátních klíčů nebo tajných kódů certifikátů, které chrání identity entit zahrnutých v zajišťování a zřizování certifikátů.

Popisujeme správu certifikátů jako procesy a postupy, které se používají k získání certifikátů a k jejich bezpečnému a bezpečnému přenosu do místa, kde jsou potřeba.

Některé operace správy, jako je registrace, nastavení zásad a ovládací prvky autorizace, jsou nad rámec tohoto článku. Jiné operace, jako je zřizování, prodloužení platnosti, opětovné vytvoření klíče nebo odvolání, souvisí pouze s Service Fabric. Článek je ale poněkud řeší, protože porozumění těmto operacím vám může pomoct správně zabezpečit cluster.

Vaším okamžitým cílem je pravděpodobně automatizovat správu certifikátů co nejvíce, aby se zajistila nepřerušovaná dostupnost clusteru. Vzhledem k tomu, že proces je bez uživatelského ovládání, budete také chtít nabídnout bezpečnostní záruky. S clustery Service Fabric je tento cíl dosažitelný.

Zbývající část článku nejprve dekonstruuje správu certifikátů a později se zaměřuje na povolení automatického registrace.

Konkrétně se zabývá následujícími tématy:

• Předpoklady týkající se oddělení přisuzování mezi vlastníkem a platformou
• Dlouhý kanál od vystavování certifikátů ke spotřebě
• Obměně certifikátů: Proč, jak a kdy
• Co by se mohlo pokazit?

Článek se nezabývá těmito tématy:

• Zabezpečení a správa názvů domén
• Registrace do certifikátů
• Nastavení autorizačních ovládacích prvků pro vynucení vystavování certifikátů

Informace o těchto tématech najdete v registrační autoritě (RA) vaší oblíbené služby infrastruktury veřejných klíčů (PKI). Pokud jste interní čtenář Microsoftu, můžete se spojit se zabezpečením Azure.

Role a entity zapojené do správy certifikátů

Přístup zabezpečení v clusteru Service Fabric je případ "vlastník clusteru ho deklaruje, modul runtime Service Fabric ho vynucuje". To znamená, že téměř žádná z certifikátů, klíčů nebo jiných přihlašovacích údajů identit, které se účastní fungování clusteru, pochází ze samotné služby. Všechny jsou deklarovány vlastníkem clusteru. Vlastník clusteru také zodpovídá za zřizování certifikátů do clusteru, jejich obnovení podle potřeby a zajištění jejich zabezpečení za všech okolností.

Konkrétně vlastník clusteru musí zajistit, aby:

• Certifikáty deklarované v části NodeType manifestu clusteru najdete na každém uzlu tohoto typu podle pravidel prezentace.
• Certifikáty deklarované jako v předchozím odrážkovém bodu se nainstalují s odpovídajícími privátními klíči.
• Certifikáty deklarované v pravidlech prezentace by měly předávat ověřovací pravidla.

Service Fabric ve své části předpokládá následující odpovědnosti:

• Vyhledání certifikátů odpovídajících deklaracím v definici clusteru
• Udělení přístupu k odpovídajícím privátním klíčům pro entity řízené Service Fabric podle potřeby
• Ověřování certifikátů v přísném souladu se zavedenými osvědčenými postupy zabezpečení a definicí clusteru
• Vyvolávání upozornění na blížící se vypršení platnosti certifikátů nebo selhání provádění základních kroků ověření certifikátu
• Ověřování (do určité míry), že aspekty definice clusteru související s certifikáty jsou splněny základní konfigurací hostitelů.

Z toho vyplývá, že zátěž správy certifikátů (jako aktivní operace) spadá výhradně na vlastníka clusteru. V dalších částech se podrobněji podíváme na jednotlivé operace správy, včetně dostupných mechanismů a jejich dopadu na cluster.

Cesta certifikátu

Pojďme rychle nastínit průběh certifikátu od vystavení ke spotřebě v kontextu clusteru Service Fabric:

1. Vlastník domény zaregistruje v RA domény doménu nebo předmětu, který chce přidružit k výčtu certifikátů. Certifikáty pak představují doklad o vlastnictví domény nebo subjektu.

2. Vlastník domény také v RA určí identity autorizovaných žadatele, entity, které mají oprávnění požádat o zápis certifikátů se zadanou doménou nebo subjektem.

3. Autorizovaný žadatel se pak zaregistruje do certifikátu prostřednictvím služby pro správu tajných kódů. Služba správy tajných kódů v Azure je služba Azure Key Vault, která bezpečně ukládá a umožňuje načítání tajných kódů a certifikátů autorizovanými entitami. Key Vault také prodlouží a znovu certifikát obnoví podle konfigurace v přidružených zásadách certifikátů. Key Vault používá jako zprostředkovatele identity ID Microsoft Entra.

4. Autorizovaný načítač nebo agent zřizování načte certifikát z trezoru klíčů, včetně jeho privátního klíče, a nainstaluje ho na počítače, které jsou hostitelem clusteru.

5. Služba Service Fabric (spuštěná se zvýšenými oprávněními na každém uzlu) uděluje přístup k certifikátu k povoleným entitám Service Fabric, které jsou určené místními skupinami a rozděleny mezi ServiceFabric Správa istrators a ServiceFabricAllowedUsers.

6. Modul runtime Service Fabric přistupuje k federaci a používá certifikát k navázání federace nebo k ověření příchozích požadavků od autorizovaných klientů.

7. Agent zřizování monitoruje certifikát trezoru klíčů a když zjistí obnovení, aktivuje tok zřizování. Vlastník clusteru pak v případě potřeby aktualizuje definici clusteru, aby označil záměr převést certifikát.

8. Agent zřizování nebo vlastník clusteru také zodpovídá za čištění a odstraňování nepoužívaných certifikátů.

Pro účely tohoto článku jsou první dva kroky v předchozí sekvenci většinou nesouvisející. Jediným připojením je, že běžný název subjektu certifikátu je název DNS deklarovaný v definici clusteru.

Tok vystavování a zřizování certifikátů je znázorněný v následujících diagramech:

Pro certifikáty deklarované kryptografickým otiskem

Pro certifikáty deklarované běžným názvem subjektu

Zápis certifikátu

Téma registrace certifikátu je podrobně popsané v dokumentaci ke službě Key Vault. Tady je uvedena synopze pro zajištění kontinuity a jednoduššího odkazu.

Pokračování v Azure jako kontextu a použití služby Key Vault jako služby pro správu tajných kódů musí mít autorizovaný žadatel o certifikát alespoň oprávnění ke správě certifikátů v trezoru klíčů udělený vlastníkem trezoru klíčů. Žadatel se pak zaregistruje do certifikátu následujícím způsobem:

• Žadatel vytvoří zásadu certifikátu ve službě Key Vault, která určuje doménu/předmět certifikátu, požadovaný vystavitel, typ a délku klíče, zamýšlené použití klíče a další. Další informace najdete v tématu Certifikáty ve službě Azure Key Vault.

• Žadatel vytvoří ve stejném trezoru certifikát se zásadami, které jsou zadané v předchozím kroku. To zase vygeneruje pár klíčů jako objekty trezoru a žádost o podepsání certifikátu podepsanou privátním klíčem, která se pak předá určenému vystaviteli pro podpis.

• Jakmile vystavitel nebo certifikační autorita (CA) odpoví podepsaným certifikátem, výsledek se sloučí do trezoru klíčů a data certifikátu jsou k dispozici takto:

  • V části {vaultUri}/certificates/{name}: Certifikát, včetně veřejného klíče a metadat
  • V části {vaultUri}/keys/{name}: Privátní klíč certifikátu, který je k dispozici pro kryptografické operace (wrap/unwrap, sign/verify)
  • V části {vaultUri}/secrets/{name}: Certifikát, včetně jeho privátního klíče, je k dispozici ke stažení jako nechráněný soubor PFX nebo PEM.

Vzpomeňte si, že certifikát v trezoru klíčů obsahuje chronologický seznam instancí certifikátů, které sdílejí zásadu. Verze certifikátů se vytvoří podle atributů životnosti a obnovení této zásady. Důrazně doporučujeme, aby certifikáty trezoru nesdílely předměty nebo domény nebo názvy DNS, protože může v clusteru narušovat zřizování instancí certifikátů z různých certifikátů trezoru se stejnými předměty, ale podstatně odlišnými dalšími atributy, jako jsou vystavitel, použití klíčů atd. V tomto okamžiku existuje v trezoru klíčů certifikát připravený ke spotřebě. Teď se podíváme na zbytek procesu.

Zřizování certifikátů

Zmínili jsme agenta zřizování, což je entita, která načítá certifikát, včetně jeho privátního klíče, z trezoru klíčů a nainstaluje ho na každého hostitele clusteru. (Vzpomeňte si, že Service Fabric nezřídí certifikáty.)

V kontextu tohoto článku bude cluster hostovaný na kolekci virtuálních počítačů Azure nebo škálovacích sad virtuálních počítačů Azure. V Azure můžete zřídit certifikát z trezoru pro virtuální počítač nebo službu VMSS pomocí následujících mechanismů. Předpokládá se, že agent zřizování dříve udělil oprávnění k získání oprávnění k trezoru klíčů vlastníkem trezoru klíčů.

• Ad hoc: Operátor načte certifikát z trezoru klíčů (jako PFX/PKCS #12 nebo PEM) a nainstaluje ho do každého uzlu.

  Mechanismus ad hoc se nedoporučuje, z několika důvodů, od zabezpečení až po dostupnost a nebude se zde dále probírat. Další informace najdete v nejčastějších dotazech ke škálovacím sadám virtuálních počítačů Azure.

• Jako tajný kód škálovací sady virtuálních počítačů během nasazování: Výpočetní služba načte certifikát z trezoru s podporou nasazení šablony a nainstaluje ho na každý uzel škálovací sady virtuálních počítačů, jak je popsáno v nejčastějších dotazech pro škálovací sady virtuálních počítačů Azure.

  Poznámka:

  Tento přístup umožňuje pouze zřizování tajných kódů s verzí.

• Pomocí rozšíření virtuálního počítače služby Key Vault. Díky tomu můžete zřizovat certifikáty pomocí deklarací bez verzí s pravidelnou aktualizací pozorovaných certifikátů. V tomto případě se očekává, že virtuální počítač nebo služba VMSS bude mít spravovanou identitu, identitu, která má udělený přístup k trezorům klíčů, které obsahují pozorované certifikáty.

Zřizování založené na virtuálních počítačích nebo výpočetních prostředcích představuje výhody zabezpečení a dostupnosti, ale zároveň představuje omezení. Vyžaduje, abyste certifikáty deklarovali jako tajné kódy s verzí. Díky tomuto požadavku je zřizování založené na virtuálních počítačích/výpočetních prostředcích vhodné jenom pro clustery zabezpečené pomocí certifikátů deklarovaných kryptografickým otiskem.

Naproti tomu zřizování založené na rozšířeních virtuálních počítačů služby Key Vault vždy nainstaluje nejnovější verzi každého pozorovaného certifikátu. díky tomu je vhodný pouze pro clustery zabezpečené pomocí certifikátů deklarovaných běžným názvem subjektu. Pokud chcete zdůraznit, nepoužívejte mechanismus zřizování autorefresh (například rozšíření virtuálního počítače služby Key Vault) pro certifikáty deklarované instancí (tj. kryptografickým otiskem). Riziko ztráty dostupnosti je značné.

Existují i další mechanismy zřizování, ale zde uvedené přístupy jsou aktuálně přijímané možnosti pro clustery Azure Service Fabric.

Využití a monitorování certifikátů

Jak už bylo zmíněno dříve, modul runtime Service Fabric zodpovídá za vyhledání a používání certifikátů deklarovaných v definici clusteru. Článek o ověřování založeném na certifikátech X.509 v clusterech Service Fabric podrobně vysvětluje, jak Service Fabric implementuje prezentační a ověřovací pravidla a nebude se zde znovu opakovat. Tento článek se bude zabývat udělením přístupu a oprávnění a také monitorováním.

Vzpomeňte si, že certifikáty ve službě Service Fabric se používají pro celou řadu účelů– od vzájemného ověřování ve vrstvě federace až po ověřování TLS (Transport Layer Security) pro koncové body správy. To vyžaduje, aby různé komponenty nebo systémové služby měly přístup k privátnímu klíči certifikátu. Modul runtime Service Fabric pravidelně kontroluje úložiště certifikátů a hledá shody pro každou z známých pravidel prezentace.

Pro každý odpovídající certifikát se nachází odpovídající privátní klíč a jeho volitelný seznam řízení přístupu se aktualizuje tak, aby zahrnoval oprávnění (obvykle read and Execute), která jsou udělena identitě, která je vyžaduje.

Tento proces se neformálně označuje jako ACLing. Proces běží na minutovém tempu a vztahuje se také na certifikáty aplikací , jako jsou například certifikáty používané k šifrování nastavení nebo jako certifikáty koncových bodů. ACLing se řídí pravidly prezentace, takže je důležité mít na paměti, že certifikáty deklarované kryptografickým otiskem a které se automaticky provedou bez aktualizace konfigurace clusteru, budou nedostupné.

Obměně certifikátů

Poznámka:

Internet Engineering Task Force (IETF) RFC 3647 formálně definuje obnovení jako vystavení certifikátu se stejnými atributy jako certifikát, který se nahrazuje. Vystavitel, veřejný klíč subjektu a informace se zachovají. Opětovné vytvoření klíče je vystavení certifikátu s novou dvojicí klíčů bez omezení, jestli se vystavitel může změnit. Vzhledem k tomu, že rozdíl může být důležitý (zvažte případ certifikátů deklarovaných běžným názvem subjektu s připnutím vystavitele), tento článek používá neutrální obměnu termínů k pokrytí obou scénářů. Mějte na paměti, že pokud se obnovení používá neformálně, odkazuje na opětovné vytvoření klíče.

Jak už bylo zmíněno dříve, Služba Key Vault podporuje automatickou obměnu certifikátů. To znamená, že zásada přidružení certifikátu definuje bod v čase, ať už po dnech před vypršením platnosti nebo procentem celkové životnosti, když se certifikát v trezoru klíčů otočí. Agent zřizování se musí vyvolat po tomto bodu v čase a před vypršením platnosti nyní předchozího certifikátu distribuovat tento nový certifikát do všech uzlů clusteru.

Service Fabric pomáhá v tomto procesu vyvoláním upozornění na stav v případě, že datum vypršení platnosti certifikátu, které se aktuálně používá v clusteru, nastane dříve než předem určený interval. Agent automatického zřizování, rozšíření virtuálního počítače služby Key Vault, které je nakonfigurované pro sledování certifikátu trezoru klíčů, pravidelně se dotazuje na trezor klíčů, zjišťuje rotaci a načítá a nainstaluje nový certifikát. Zřizování, které probíhá prostřednictvím funkce tajných kódů virtuálního počítače nebo VMSSS, vyžaduje autorizovaného operátora, aby aktualizoval virtuální počítač nebo VMSS pomocí identifikátoru URI služby Key Vault s verzí, který odpovídá novému certifikátu.

Otočený certifikát je teď zřízený pro všechny uzly. Nyní za předpokladu, že rotace použitá na certifikát clusteru byla deklarována běžným názvem subjektu, pojďme se podívat, co se stane dál:

• V případě nových připojení v rámci clusteru i v clusteru modul runtime Service Fabric vyhledá a vybere naposledy vydaný odpovídající certifikát (největší hodnota notBefore vlastnosti). Jedná se o změnu ze starších verzí modulu runtime Service Fabric.

• Stávající připojení jsou udržována naživu nebo mohou přirozeně vypršet nebo jinak ukončit a interní obslužná rutina bude upozorněna, že existuje nová shoda.

Poznámka:

V současné době Service Fabric od verze 7.2 CU4+ vybere certifikát s nejvyšší hodnotou vlastnosti NotBefore (naposledy vydaný). Před 7.2 CU4 služba Service Fabric vybrala platný certifikát s nejvyšší hodnotou NotAfter (nejnovější vypršení platnosti).

To se překládá na následující důležitá pozorování:

• Dostupnost clusteru nebo hostovaných aplikací má přednost před direktivou, aby se certifikát otočil. Cluster se nakonec shoduje s novým certifikátem, ale bez záruk načasování. Z toho vyplývá, že:

  • Pozorovateli nemusí být okamžitě zřejmé, že obměněný certifikát zcela nahradil svého předchůdce. Jediným způsobem, jak vynutit okamžité nahrazení aktuálně používaného certifikátu, je restartovat hostitelské počítače. Restartování uzlů Service Fabric nestačí, protože na součásti režimu jádra, které tvoří připojení zapůjčení v clusteru, nebudou ovlivněny. Restartování virtuálního počítače nebo služby VMSS může také způsobit dočasnou ztrátu dostupnosti. U certifikátů aplikací stačí restartovat pouze příslušné instance aplikace.

  • Představujeme znovu klíčovaný certifikát, který nesplňuje ověřovací pravidla, může cluster efektivně narušit. Nejběžnějším příkladem je neočekávaný vystavitel, kdy jsou certifikáty clusteru deklarovány běžným názvem subjektu s připnutím vystavitele, ale otočený certifikát vydal nový nebo nedeklaný vystavitel.

Vyčištění certifikátu

V tuto chvíli v Azure nejsou k dispozici žádná ustanovení pro explicitní odebrání certifikátů. Často se jedná o netiktivní úlohu, která určuje, jestli se konkrétní certifikát používá v konkrétní době. To je pro certifikáty aplikací obtížnější než u certifikátů clusteru. Service Fabric sám, ne jako agent zřizování, neodstraní certifikát deklarovaný uživatelem za žádných okolností. Pro standardní mechanismy zřizování:

• Certifikáty deklarované jako tajné kódy VM/VMSS se zřizují, pokud se na tyto certifikáty odkazují v definici virtuálního počítače nebo VMSS a načítají se z trezoru klíčů. Odstranění tajného klíče trezoru klíčů nebo certifikátu selže při následných nasazeních virtuálních počítačů nebo VMSS. Podobně zakázání verze tajného kódu v trezoru klíčů také selže nasazení virtuálních počítačů nebo VMSS, která odkazují na verzi tajného kódu.

• Starší verze certifikátů, které jsou zřízené prostřednictvím rozšíření virtuálního počítače key Vault, můžou nebo nemusí být přítomné na uzlu VM/VMSS. Agent načte a nainstaluje pouze aktuální verzi a neodebere žádné certifikáty. Opětovné vytvoření image uzlu, který obvykle probíhá každý měsíc, resetuje úložiště certifikátů na obsah image operačního systému, takže starší verze se implicitně odeberou. Zvažte ale, že vertikální navýšení kapacity škálovací sady virtuálních počítačů způsobí instalaci pouze aktuální verze pozorovaných certifikátů. Nepředpokládejte homogenitu uzlů s ohledem na nainstalované certifikáty.

Zjednodušení správy: Příklad automatického registrace

V tomto článku jsme zatím popsali mechanismy a omezení, popsali složitá pravidla a definice a předpovídaly výpadky. Teď je čas nastavit automatickou správu certifikátů, abyste se vyhnuli všem těmto obavám. Pojďme to udělat v kontextu clusteru Azure Service Fabric běžícího na škálovací sadě virtuálních počítačů PaaS (Platforma jako služba) v2 s využitím služby Key Vault pro správu tajných kódů a využití spravovaných identit následujícím způsobem:

• Ověření certifikátů se změní z připnutí kryptografického otisku na předmět + připnutí vystavitele. Jakýkoli certifikát s konkrétním subjektem od konkrétního vystavitele je stejně důvěryhodný.
• Certifikáty se registrují a získávají z důvěryhodného úložiště (Key Vault) a aktualizují ho agent (tady rozšíření virtuálního počítače služby Key Vault).
• Zřizovánícertifikátůchm
• Přístup k trezoru klíčů se uděluje prostřednictvím spravovaných identit přiřazených uživatelem, které se vytvářejí a přiřazují škálovací sadě virtuálních počítačů během nasazování.
• Po nasazení se agent (rozšíření virtuálního počítače Key Vault) dotazuje a aktualizuje zjištěné certifikáty na každém uzlu škálovací sady virtuálních počítačů. Obměně certifikátů je tedy plně automatizovaná, protože Service Fabric automaticky převezme nejnovější platný certifikát.

Sekvence je plně skriptovatelná a automatizovaná a umožňuje počáteční nasazení clusteru bez dotykového ovládání, který je nakonfigurovaný pro automatický zápis certifikátu. Další části obsahují podrobný postup, který obsahuje kombinaci rutin PowerShellu a fragmentů šablon JSON. Stejné funkce jsou dosažitelné se všemi podporovanými prostředky interakce s Azure.

Poznámka:

Tento příklad předpokládá, že certifikát již existuje ve vašem trezoru klíčů. Registrace a obnovení certifikátu spravovaného službou Key Vault vyžaduje požadované ruční kroky, jak je popsáno výše v tomto článku. Pro produkční prostředí použijte certifikáty spravované službou Key Vault. Zahrnuli jsme ukázkový skript, který je specifický pro interní pkI Od Microsoftu.

Poznámka:

Automatický zápis certifikátu dává smysl jenom pro certifikáty vydané certifikační autoritou. Použití certifikátů podepsaných svým držitelem, včetně certifikátů vygenerovaných během nasazování clusteru Service Fabric na webu Azure Portal, je nesmyslné, ale pro místní nasazení nebo nasazení hostované vývojářem je možné, pokud deklarujete kryptografický otisk vystavitele, aby byl stejný jako u certifikátu typu list.

Bodem

Pro stručnost předpokládejme následující počáteční stav:

• Cluster Service Fabric existuje a je zabezpečený certifikátem vydaným certifikační autoritou deklarovaným kryptografickým otiskem.
• Certifikát se uloží do trezoru klíčů a zřídí se jako tajný klíč škálovací sady virtuálních počítačů.
• Stejný certifikát se použije k převodu clusteru na běžné deklarace certifikátů založené na názvu, takže ho může ověřit subjekt a vystavitel. Pokud tomu tak není, získejte certifikát vydaný certifikační autoritou, který je určený pro tento účel, a přidejte ho do definice clusteru kryptografickým otiskem. Tento proces je vysvětlený v části Přidání nebo odebrání certifikátů pro cluster Service Fabric v Azure.

Tady je výňatek JSON ze šablony, která odpovídá takovému stavu. Výňatek vynechá mnoho požadovaných nastavení a ilustruje pouze aspekty související s certifikáty.

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

Předchozí kód v podstatě říká, že certifikát s kryptografickým otiskem json [parameters('primaryClusterCertificateTP')] a nalezený v identifikátoru URI json [parameters('clusterCertificateUrlValue')] služby Key Vault je deklarován jako jediný certifikát clusteru kryptografickým otiskem.

V dalším kroku nastavíme další prostředky potřebné k zajištění automatického registrace certifikátu.

Nastavení požadovaných prostředků

Jak už bylo zmíněno dříve, certifikát zřízený jako tajný klíč škálovací sady virtuálních počítačů se načítá z trezoru klíčů službou Microsoft Compute Resource Provider. Provede to použitím identity první strany jménem operátora nasazení. Tento proces se změní pro automatický zápis. Přepnete na použití spravované identity, která je přiřazená ke škálovací sadě virtuálních počítačů a která má udělená oprávnění GET k tajným kódům v daném trezoru.

Měli byste nasadit další výňatky najednou. Jsou uvedeny jednotlivě pouze pro analýzu a vysvětlení play-by-play.

Nejprve definujte identitu přiřazenou uživatelem (jako příklady jsou zahrnuty výchozí hodnoty). Další informace najdete v oficiální dokumentaci.

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

Dále udělte této identitě přístup k tajným klíčům trezoru klíčů. Nejaktuálnější informace najdete v oficiální dokumentaci.

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

V dalším kroku provedete následující kroky:

• Přiřaďte identitu přiřazenou uživatelem ke škálovací sadě virtuálních počítačů.
• Deklarujte závislost škálovací sady virtuálních počítačů na vytvoření spravované identity a na výsledku udělení přístupu k trezoru klíčů.
• Deklarujte rozšíření virtuálního počítače služby Key Vault a vyžadovat, aby při spuštění načetl zjištěné certifikáty. Další informace najdete v oficiální dokumentaci k rozšíření virtuálního počítače služby Key Vault pro Windows .
• Aktualizujte definici rozšíření virtuálního počítače Service Fabric tak, aby závisela na rozšíření virtuálního počítače služby Key Vault, a převeďte deklaraci certifikátu clusteru z kryptografického otisku na běžný název.

Poznámka:

Tyto změny se provádějí jako jeden krok, protože spadají do rozsahu stejného prostředku.

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

I když není explicitně uvedený v předchozím kódu, mějte na paměti, že adresa URL certifikátu trezoru klíčů byla odebrána z OsProfile části škálovací sady virtuálních počítačů.

Posledním krokem je aktualizace definice clusteru, aby se změnila deklarace certifikátu z kryptografického otisku na běžný název. Připneme také kryptografické otisky vystavitele:

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

V tomto okamžiku můžete spustit dříve uvedené aktualizace v jednom nasazení. Ve své části služba Service Fabric Resource Provider rozdělí upgrade clusteru v několika krocích, jak je popsáno v segmentu při převodu certifikátů clusteru z kryptografického otisku na běžný název.

Analýza a pozorování

Tato část je catch-all pro vysvětlení konceptů a procesů, které byly prezentovány v tomto článku, a také upoutání pozornosti na některé další důležité aspekty.

Informace o zřizování certifikátů

Rozšíření virtuálního počítače služby Key Vault jako agent zřizování běží nepřetržitě na předem určené frekvenci. Pokud se nepodaří načíst pozorovaný certifikát, pokračuje na další řádek a hibernuje až do dalšího cyklu. Rozšíření virtuálního počítače Service Fabric, jako agent spouštění clusteru, vyžaduje před vytvořením clusteru deklarované certifikáty. To zase znamená, že rozšíření virtuálního počítače Service Fabric může běžet až po úspěšném načtení certifikátů clusteru, které zde json "provisionAfterExtensions" : [ "KVVMExtension" ]" uvádí klauzule, a nastavením rozšíření json "requireInitialSync": true virtuálního počítače služby Key Vault.

To značí rozšíření virtuálního počítače služby Key Vault, že při prvním spuštění (po nasazení nebo restartování) musí cyklicky procházet zjištěné certifikáty, dokud se všechny úspěšně nestáhnou. Nastavení tohoto parametru na hodnotu false v kombinaci s chybou načtení certifikátů clusteru by vedlo k selhání nasazení clusteru. Pokud naopak vyžadujete počáteční synchronizaci s nesprávným nebo neplatným seznamem pozorovaných certifikátů, dojde k selhání rozšíření virtuálního počítače služby Key Vault a dalším selháním nasazení clusteru.

Propojení certifikátů, vysvětlení

Možná jste si všimli příznaku rozšíření linkOnRenewal služby Key Vault a skutečnosti, že je nastavená na false. Toto nastavení řeší chování řízené tímto příznakem a jeho důsledky na fungování clusteru. Toto chování je specifické pro Systém Windows.

Podle jeho definice:

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

Certifikáty používané k navázání připojení TLS se obvykle získávají jako popisovač prostřednictvím zprostředkovatele podpory zabezpečení S-channel. To znamená, že klient nemá přímý přístup k privátnímu klíči samotného certifikátu. Kanál S-channel podporuje přesměrování přihlašovacích údajů (neboli propojení) ve formě rozšíření certifikátu CERT_RENEWAL_PROP_ID.

Pokud je tato vlastnost nastavena, její hodnota představuje kryptografický otisk certifikátu pro obnovení , a proto se kanál S místo toho pokusí načíst propojený certifikát. Ve skutečnosti bude kanál S procházet tuto propojenou a doufejme, že cyklický seznam, dokud skončí s posledním certifikátem, jeden bez značky pro obnovení. Tato funkce, pokud se používá uvážlivě, je skvělým řešením pro ztrátu dostupnosti, která je způsobená například prošlými certifikáty.

V jiných případech může být příčinou výpadků, které je obtížné diagnostikovat a zmírnit. S-channel provádí procházení certifikátů na svých vlastnostech obnovení bezpodmínečně, bez ohledu na subjekt, vystavitele nebo jakékoli jiné konkrétní atributy, které se účastní ověření výsledného certifikátu klientem. Je možné, že výsledný certifikát nemá přidružený privátní klíč nebo že klíč nebyl přiřazen ke svému potenciálnímu příjemci.

Pokud je propojení povolené, rozšíření virtuálního počítače služby Key Vault, když načte pozorovaný certifikát z trezoru klíčů, pokusí se najít odpovídající existující certifikáty, které je propojí prostřednictvím vlastnosti rozšíření pro prodloužení platnosti. Porovnávání je založeno výhradně na alternativním názvu subjektu (SAN) a funguje, pokud existují dva existující certifikáty, jak je znázorněno v následujících příkladech: A: Název certifikátu (CN) = "Příslušenství Alice", SAN = {"alice.universalexports.com"}, prodloužení = '' B: CN = "Bobovy bity", SAN = {"bob.universalexports.com", "bob.universalexports.net"}, prodloužení = ''

Předpokládejme, že rozšíření virtuálního počítače key Vaultu načte certifikát C: CN = "Malware Mallory", SAN = {"alice.universalexports.com", "bob.universalexports.com", "mallory.universalexports.com"}

Seznam SAN certifikátu A je plně zahrnutý do seznamu C a proto A.renewal = C.thumbprint. Seznam SAN certifikátu B má společný průsečík s C, ale není v něm plně zahrnutý, takže B.renewal zůstane prázdný.

Jakýkoli pokus o vyvolání AcquireCredentialsHandle (S-channel) v tomto stavu na certifikátu A skutečně skončí odesláníM jazyka C vzdálené straně. V případě Service Fabric používá subsystém Přenosu clusteru pro vzájemné ověřování kanál S, takže dříve popsané chování ovlivňuje základní komunikaci clusteru přímo. Pokračování v předchozím příkladu a za předpokladu, že A je certifikát clusteru, co se stane dál, závisí na:

• Pokud privátní klíč jazyka C není ACL k účtu, který service Fabric běží, zobrazí se selhání získání privátního klíče (SEC_E_UNKNOWN_CREDENTIALS nebo podobné).
• Pokud je privátní klíč jazyka C přístupný, zobrazí se chyby autorizace vrácené jinými uzly (CertificateNotMatched, neautorizováno atd.).

V obou případech se přenos nezdaří a cluster se může snížit. Příznaky se liší. Aby to bylo horší, propojení závisí na pořadí obnovení, které je diktováno pořadím pozorovaných certifikátů rozšíření virtuálního počítače služby Key Vault, plánem obnovení v trezoru klíčů nebo dokonce přechodnými chybami, které by změnily pořadí načítání.

Pokud chcete tyto incidenty zmírnit, doporučujeme následující:

• Nekombinujte alternativní názvy různých certifikátů trezoru. Každý certifikát trezoru by měl sloužit k odlišnému účelu a jeho předmět a síť SAN by měly odrážet určitou specifikitu.

• Do seznamu SAN zahrňte běžný název subjektu (jako, doslova). CN=<subject common name>

• Pokud si nejste jistí, jak pokračovat, zakažte propojení pro certifikáty zřízené s rozšířením virtuálního počítače služby Key Vault.

  Poznámka:

  Zakázání propojení je vlastnost nejvyšší úrovně rozšíření virtuálního počítače služby Key Vault a nedá se nastavit pro jednotlivé pozorované certifikáty.

Proč mám používat spravovanou identitu přiřazenou uživatelem? Jaké jsou důsledky jeho používání?

Jak bylo zřejmé z předchozích fragmentů kódu JSON, vyžaduje se konkrétní sekvencování operací a aktualizací, aby se zajistil úspěch převodu a zachovala dostupnost clusteru. Konkrétně prostředek škálovací sady virtuálních počítačů deklaruje a používá svou identitu k načtení tajných kódů v jedné aktualizaci (z pohledu uživatele).

Rozšíření virtuálního počítače Service Fabric, které spouští cluster, závisí na dokončení rozšíření virtuálního počítače služby Key Vault, které zase závisí na úspěšném načtení pozorovaných certifikátů.

Rozšíření virtuálního počítače služby Key Vault používá identitu škálovací sady virtuálních počítačů pro přístup k trezoru klíčů, což znamená, že zásady přístupu v trezoru klíčů už musí být před nasazením škálovací sady virtuálních počítačů aktualizované.

Pokud chcete likvidovat vytvoření spravované identity nebo ji přiřadit jinému prostředku, musí mít operátor nasazení kromě rolí, na které se v šabloně odkazuje, požadovanou roli (ManagedIdentityOperator) v předplatném nebo skupině prostředků.

Z hlediska zabezpečení si vzpomeňte, že škálovací sada virtuálních počítačů se považuje za hranici zabezpečení, pokud jde o její identitu Azure. To znamená, že každá aplikace hostovaná na virtuálním počítači může v zásadě získat přístupový token představující virtuální počítač. Přístupové tokeny spravované identity se získávají z neověřeného koncového bodu služby Metadata Instance. Pokud považujete virtuální počítač za sdílený nebo prostředí s více tenanty, nemusí být tato metoda načítání certifikátů clusteru označená. Jedná se však o jediný mechanismus zřizování vhodný pro automatický zápis certifikátu.

Řešení potíží a nejčastější dotazy

Otázka: Jak se můžu programově zaregistrovat do certifikátu spravovaného službou Key Vault?

V dokumentaci ke službě Key Vault zjistěte název vystavitele a pak ho nahraďte následujícím skriptem:

  $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 

Otázka: Co se stane, když je certifikát vystavený nedelarovaným nebo nespecifikovaným vystavitelem? Kde můžu získat úplný seznam aktivních vystavitelů konkrétní infrastruktury veřejných klíčů?

Pokud deklarace certifikátu určuje kryptografické otisky vystavitele a přímý vystavitel certifikátu není součástí seznamu připnutých vystavitelů, bude certifikát považován za neplatný, ať už je jeho kořen důvěryhodný klientem. Proto je důležité zajistit, aby seznam vystavitelů byl aktuální. Zavedení nového vystavitele je vzácná událost a měla by být široce veřejná, než začne vydávat certifikáty.

Infrastruktura veřejných klíčů obecně publikuje a udržuje prohlášení o certifikační praxi v souladu s dokumentem IETF RFC 7382. Kromě dalších informací obsahuje příkaz všechny aktivní vystavitele. Načítání tohoto seznamu se může programově lišit od jedné infrastruktury veřejných klíčů k druhému.

V případě interních veřejných klíčů Microsoftu se nezapomeňte podívat do interní dokumentace k koncovým bodům a sadám SDK, které se používají k načtení autorizovaných vystavitelů. Za pravidelnou kontrolu tohoto seznamu zodpovídá vlastník clusteru, aby se zajistilo, že definice clusteru zahrnuje všechny očekávané vystavitele.

Otázka: Podporuje se více veřejných klíčů?

Ano. V manifestu clusteru nesmíte deklarovat více položek CN se stejnou hodnotou, ale můžete vypsat vystavitele z více pkI, které odpovídají stejné cn. Nejedná se o doporučený postup a postupy transparentnosti certifikátů můžou bránit vydávání takových certifikátů. Jako prostředek pro migraci z jedné infrastruktury veřejných klíčů do jiného je to ale přijatelný mechanismus.

Otázka: Co když aktuální certifikát clusteru není vystavený certifikační autoritou nebo nemá zamýšlený předmět?

Získejte certifikát s zamýšleným předmětem a přidejte ho do definice clusteru jako sekundární kryptografický otisk. Po úspěšném dokončení upgradu zahajte další upgrade konfigurace clusteru a převeďte deklaraci certifikátu na běžný název.