Megosztás a következőn keresztül:

Tanúsítványok kezelése Service Fabric-fürtökben

  • Cikk

Ez a cikk az Azure Service Fabric-fürtökben való kommunikáció biztonságossá tételéhez használt tanúsítványok felügyeleti szempontjait ismerteti. Kiegészíti a Service Fabric-fürtbiztonság és az X.509 tanúsítványalapú hitelesítés magyarázatát a Service Fabricben.

Előfeltételek

A kezdés előtt ismernie kell az alapvető biztonsági fogalmakat és azokat a vezérlőket, amelyeket a Service Fabric elérhetővé tesz a fürt biztonságának konfigurálásához.

Felelősséget kizáró nyilatkozat

Ez a cikk gyakorlati példákkal párosítja a tanúsítványkezelés elméleti aspektusait, amelyek a szolgáltatások, technológiák stb. sajátosságait ismertetik. Mivel a célközönség nagy része a Microsoft belső, a cikk az Azure-ra jellemző szolgáltatásokra, technológiákra és termékekre hivatkozik. Ha bizonyos Microsoft-specifikus részletek nem vonatkoznak Önre, kérjen pontosítást vagy útmutatást a megjegyzések szakasz végén.

Tanúsítványkezelés meghatározása

Ahogy az X.509 tanúsítványalapú hitelesítés a Service Fabric-fürtökben című cikkből megtudhatja, a tanúsítvány egy olyan titkosítási objektum, amely lényegében egy aszimmetrikus kulcspárt köt össze az általa képviselt entitást leíró attribútumokkal.

A tanúsítvány azonban egy romlandó objektum is, mivel élettartama véges, és veszélyben van. A véletlen közzététel vagy a sikeres kihasználtság biztonsági szempontból használhatatlanná teheti a tanúsítványokat. Ez a jellemző azt jelenti, hogy rutinszerűen vagy biztonsági incidensre válaszul módosítani kell a tanúsítványokat.

A tanúsítványkezelés másik aspektusa és egy teljesen különálló témakör a tanúsítványok titkos kulcsainak vagy titkos kulcsainak védelme, amelyek védik a tanúsítványok beszerzésében és kiépítésében részt vevő entitások identitásait.

A tanúsítványkezelést a tanúsítványok beszerzéséhez és biztonságos és biztonságos szállításához használt folyamatokként és eljárásokként írjuk le.

Egyes felügyeleti műveletek, például a regisztráció, a házirend-beállítás és az engedélyezési vezérlők túlmutatnak a jelen cikk hatókörén. Más műveletek, például a kiépítés, a megújítás, az újrakulcsolás vagy a visszavonás csak a Service Fabrichez kapcsolódnak. A cikk azonban némileg foglalkozik velük, mivel ezeknek a műveleteknek a megértése segíthet a fürt megfelelő védelmében.

Az azonnali cél valószínűleg az, hogy a lehető legnagyobb mértékben automatizálja a tanúsítványkezelést a fürt folyamatos rendelkezésre állásának biztosítása érdekében. Mivel a folyamat érintésmentes, biztonsági garanciákat is biztosítani kell. A Service Fabric-fürtök esetén ez a cél elérhető.

A cikk további része először a tanúsítványkezelést dekonstruálja, majd az automatikus regisztráció engedélyezésére összpontosít.

Konkrétan a következő témaköröket ismerteti:

  • Feltételezések a tulajdonos és a platform közötti hozzárendelések elkülönítéséről
  • A hosszú folyamat a tanúsítvány kiállításától a felhasználásig
  • Tanúsítvány rotálása: Miért, hogyan és mikor
  • Mi lehet a baj?

A cikk az alábbi témaköröket nem ismerteti:

  • Tartománynevek védelme és kezelése
  • Regisztráció tanúsítványokba
  • Engedélyezési vezérlők beállítása a tanúsítvány kiállításának kényszerítéséhez.

Ezekről a témakörökről a kedvenc nyilvános kulcsú infrastruktúra (PKI) szolgáltatásának regisztrációs szolgáltatójához (RA) tájékozódhat. Ha Ön a Microsoft belső olvasója, kapcsolatba léphet az Azure Security szolgáltatással.

A tanúsítványkezelésben részt vevő szerepkörök és entitások

A Service Fabric-fürtök biztonsági megközelítése a "fürttulajdonos deklarálja, a Service Fabric-futtatókörnyezet kényszeríti". Ez azt jelenti, hogy a fürt működésében részt vevő identitások tanúsítványai, kulcsai és egyéb hitelesítő adatai szinte egyike sem magától a szolgáltatástól származik. Ezeket a fürt tulajdonosa deklarálja. A fürt tulajdonosa felelős azért is, hogy a tanúsítványokat kiépítse a fürtbe, szükség szerint megújítsa őket, és mindig biztosítsa a biztonságukat.

Pontosabban a fürt tulajdonosának biztosítania kell, hogy:

  • A fürtjegyzék NodeType szakaszában deklarált tanúsítványok az adott típusú csomópontokon találhatók a bemutató szabályainak megfelelően.
  • Az előző listajelpontként deklarált tanúsítványok a hozzájuk tartozó titkos kulcsokkal együtt vannak telepítve.
  • A bemutatószabályokban deklarált tanúsítványoknak át kell adniuk az érvényesítési szabályokat.

A Service Fabric a maga részéről a következő feladatokat vállalja:

  • A fürtdefinícióban szereplő deklarációknak megfelelő tanúsítványok keresése
  • Hozzáférés biztosítása a megfelelő titkos kulcsokhoz a Service Fabric által ellenőrzött entitásokhoz igény szerint
  • Tanúsítványok ellenőrzése a már bevált ajánlott biztonsági eljárásokkal és a fürtdefinícióval összhangban
  • Riasztások létrehozása a tanúsítványok közelgő lejáratáról, vagy a tanúsítványérvényesítés alapvető lépéseinek végrehajtásával kapcsolatos hibákról
  • Annak ellenőrzése (bizonyos mértékig), hogy a fürtdefiníció tanúsítványsal kapcsolatos szempontjait a gazdagépek mögöttes konfigurációja teljesíti

Ebből következik, hogy a tanúsítványkezelési terhek (aktív műveletekként) kizárólag a fürt tulajdonosára hárulnak. A következő szakaszok részletesebben is áttekintik az egyes felügyeleti műveleteket, beleértve a rendelkezésre álló mechanizmusokat és azok fürtre gyakorolt hatását.

A tanúsítvány menete

Röviden vázoljuk fel a tanúsítványnak a kiállítástól a használatig való előrehaladását a Service Fabric-fürt környezetében:

  1. A tartománytulajdonos regisztrál egy PKI RA-ján egy olyan tartományt vagy tárgyat, amelyet társítani szeretne az azt kibocsátó tanúsítványokkal. A tanúsítványok viszont a tartomány vagy a tulajdonos tulajdonjogának igazolását jelentik.

  2. A tartománytulajdonos az RA-ban kijelöli az engedélyezett kérelmezők identitásait, azokat az entitásokat is, amelyek jogosultak a megadott tartományhoz vagy tulajdonoshoz tartozó tanúsítványok regisztrációjának igénylésére.

  3. Egy jogosult kérelmező ezután egy titkos kódkezelő szolgáltatáson keresztül regisztrál egy tanúsítványra. Az Azure-ban a választott titkos kulcskezelési szolgáltatás az Azure Key Vault, amely biztonságosan tárolja és engedélyezi a titkos kódok és tanúsítványok lekérését az engedélyezett entitások számára. A Key Vault emellett megújítja és újrakulcsozza a tanúsítványt a társított tanúsítványszabályzatban konfigurált módon. A Key Vault a Microsoft Entra-azonosítót használja identitásszolgáltatóként.

  4. Egy jogosult lekérő vagy kiépítési ügynök lekéri a tanúsítványt a kulcstartóból, beleértve a titkos kulcsát is, és telepíti a fürtöt üzemeltető gépekre.

  5. A Service Fabric szolgáltatás (minden csomóponton emelt szintű futtatás) hozzáférést biztosít a tanúsítványhoz a helyi csoportok által kijelölt és a ServiceFabric Rendszergazda istrators és a ServiceFabricAllowedUsers között felosztott Engedélyezett Service Fabric-entitásokhoz.

  6. A Service Fabric futtatókörnyezete hozzáfér és a tanúsítvány használatával összevonást hoz létre, vagy hitelesíti az engedélyezett ügyfelek bejövő kéréseit.

  7. A kiépítési ügynök figyeli a kulcstartó tanúsítványát, és amikor észleli a megújítást, aktiválja a kiépítési folyamatot. A fürt tulajdonosa ezután szükség esetén frissíti a fürtdefiníciót, hogy jelezze a tanúsítvány átgördítési szándékát.

  8. A kiépítési ügynök vagy a fürt tulajdonosa felelős a nem használt tanúsítványok eltávolításáért és törléséért is.

A cikk alkalmazásában az előző sorozat első két lépése többnyire nem kapcsolódik egymáshoz. Az egyetlen kapcsolat az, hogy a tanúsítvány tulajdonosának közös neve a fürtdefinícióban deklarált DNS-név.

A tanúsítvány kiállításának és kiépítésének folyamatát az alábbi diagramok szemléltetik:

Ujjlenyomattal deklarált tanúsítványok esetén

Diagram of provisioning certificates that are declared by thumbprint.

Tulajdonos közös neve által deklarált tanúsítványok esetén

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

Tanúsítványregisztráció

A tanúsítványregisztráció témakörét részletesen ismerteti a Key Vault dokumentációja. A folyamatosság és a könnyebb referencia érdekében itt egy szinopszis található.

Ha továbbra is az Azure-t használja a környezetként, és a Key Vaultot a titkos kulcskezelési szolgáltatásként használja, a jogosult tanúsítványkérelmeknek legalább tanúsítványkezelési engedélyekkel kell rendelkezniük a kulcstartón, amelyet a kulcstartó tulajdonosa adott meg. A kérelmező ezután a következőképpen regisztrál egy tanúsítványra:

  • A kérelmező létrehoz egy tanúsítványszabályzatot a Key Vaultban, amely meghatározza a tanúsítvány tartományát/tárgyát, a kívánt kiállítót, a kulcs típusát és hosszát, a kívánt kulcshasználatot és egyebeket. További információ: Tanúsítványok az Azure Key Vaultban.

  • A kérelmező létrehoz egy tanúsítványt ugyanabban a tárolóban az előző lépésben megadott szabályzattal. Ez viszont létrehoz egy kulcspárt tárolóobjektumként, valamint egy tanúsítvány-aláírási kérelmet, amely a titkos kulccsal van aláírva, majd továbbítja a kijelölt kiállítónak aláírásra.

  • Miután a kiállító vagy a hitelesítésszolgáltató (CA) válaszolt az aláírt tanúsítvánnyal, az eredmény egyesül a kulcstartóban, és a tanúsítványadatok az alábbiak szerint érhetők el:

    • Alatt {vaultUri}/certificates/{name}: A tanúsítvány, beleértve a nyilvános kulcsot és a metaadatokat
    • Alatt {vaultUri}/keys/{name}: A tanúsítvány titkos kulcsa, amely titkosítási műveletekhez érhető el (wrap/unwrap, sign/verify)
    • Alatt {vaultUri}/secrets/{name}: A tanúsítvány, beleértve a titkos kulcsát is, nem védett PFX- vagy PEM-fájlként tölthető le.

Ne feledje, hogy a kulcstartóban lévő tanúsítványok a szabályzatot használó tanúsítványpéldányok időrendi listáját tartalmazzák. A tanúsítványverziók a szabályzat élettartam- és megújítási attribútumainak megfelelően jönnek létre. Erősen javasoljuk, hogy a tárolótanúsítványok ne osszanak meg tantárgyakat, tartományokat vagy DNS-neveket, mert a fürtben zavaró lehet a különböző tárolótanúsítványokból származó tanúsítványpéldányok kiépítése azonos tárgyokkal, de lényegesen eltérő egyéb attribútumokkal, például kiállítókkal, kulcshasználatokkal stb. Ezen a ponton egy tanúsítvány létezik a kulcstartóban, amely használatra kész. Most vizsgáljuk meg a folyamat többi részét.

Tanúsítványkiépítés

Említettünk egy kiépítési ügynököt, amely az az entitás, amely lekéri a tanúsítványt, beleértve a titkos kulcsát is, a kulcstartóból, és telepíti azt a fürt minden gazdagépére. (Ne feledje, hogy a Service Fabric nem épít ki tanúsítványokat.)

A cikk kontextusában a fürt azure-beli virtuális gépek (virtuális gépek) vagy virtuálisgép-méretezési csoportok gyűjteményében lesz üzemeltetve. Az Azure-ban az alábbi mechanizmusokkal építhet ki tanúsítványt egy tárolóból egy virtuális gépre/VMSS-be. Ez feltételezi, mint korábban, hogy a kiépítési ügynök korábban titkos hozzáférést kapott a kulcstartóhoz a kulcstartó tulajdonosa által.

  • Alkalmi: Az operátor lekéri a tanúsítványt a kulcstartóból (PFX/PKCS #12 vagy PEM néven), és telepíti az egyes csomópontokra.

    Az ad-hoc mechanizmus több okból sem ajánlott, a biztonságtól a rendelkezésre állásig, és itt nem tárgyaljuk tovább. További információkért tekintse meg az Azure-beli virtuálisgép-méretezési csoportokra vonatkozó gyakori kérdéseket.

  • Virtuálisgép-méretezési csoport titkos kódjaként az üzembe helyezés során: A számítási szolgáltatás az operátor nevében a belső identitás használatával lekéri a tanúsítványt egy sablonalapú üzembe helyezésre képes tárolóból, és telepíti azt a virtuálisgép-méretezési csoport minden csomópontjára, az Azure-beli virtuálisgép-méretezési csoportokra vonatkozó gyakori kérdésekben leírtak szerint.

    Megjegyzés:

    Ez a megközelítés csak a verziószámozott titkos kódok kiépítését teszi lehetővé.

  • A Key Vault virtuálisgép-bővítmény használatával. Ez lehetővé teszi a tanúsítványok kiépítését verzió nélküli deklarációk használatával, a megfigyelt tanúsítványok rendszeres frissítésével. Ebben az esetben a virtuális gép/VMSS várhatóan felügyelt identitással rendelkezik, amely olyan identitás, amely hozzáférést kapott a megfigyelt tanúsítványokat tartalmazó kulcstartókhoz.

A VMSS/számítási alapú kiépítés biztonsági és rendelkezésre állási előnyöket biztosít, de korlátozásokat is tartalmaz. Terv szerint a tanúsítványokat verziószámozott titkos kulcsként kell deklarálni. Ez a követelmény a VMSS/számítási alapú kiépítést csak az ujjlenyomattal deklarált tanúsítványokkal védett fürtök számára teszi alkalmassá.

Ezzel szemben a Key Vault virtuális gép bővítményalapú kiépítése mindig az egyes megfigyelt tanúsítványok legújabb verzióját telepíti. ami csak a közös névvel deklarált tanúsítványokkal védett fürtök számára teszi alkalmassá. Hangsúlyozandó, hogy ne használjon automatikus visszavételi kiépítési mechanizmust (például a Key Vault virtuálisgép-bővítményt) a példányok (azaz ujjlenyomatok) által deklarált tanúsítványokhoz. A rendelkezésre állás elvesztésének kockázata jelentős.

Léteznek más kiépítési mechanizmusok is, de az itt említett megközelítések az Azure Service Fabric-fürtök jelenleg elfogadott lehetőségei.

Tanúsítványhasználat és -figyelés

Ahogy korábban említettük, a Service Fabric-futtatókörnyezet feladata a fürtdefinícióban deklarált tanúsítványok keresése és használata. A Service Fabric-fürtök X.509 tanúsítványalapú hitelesítése című cikk részletesen bemutatja, hogyan implementálja a Service Fabric a bemutató és az érvényesítési szabályokat, és itt nem fogjuk újra áttekinteni. Ez a cikk a hozzáférés és az engedély megadását, valamint a monitorozást ismerteti.

Ne feledje, hogy a Service Fabric tanúsítványait számos célra használják, az összevonási rétegbeli kölcsönös hitelesítéstől a transport layer security (TLS) hitelesítésig a felügyeleti végpontok esetében. Ehhez különböző összetevőkre vagy rendszerszolgáltatásokra van szükség a tanúsítvány titkos kulcsához való hozzáféréshez. A Service Fabric-futtatókörnyezet rendszeresen ellenőrzi a tanúsítványtárolót, és megkeresi az egyes ismert bemutatószabályok egyezéseit.

Minden egyező tanúsítvány esetében a megfelelő titkos kulcs található, és a rendszer frissíti a saját hozzáférés-vezérlési listáját úgy, hogy tartalmazza azokat az engedélyeket (olvasás és végrehajtás, általában), amelyek az őket igénylő identitásnak vannak megadva.

Ezt a folyamatot nem hivatalosan ACLing-nek nevezik. A folyamat egyperces ütemben fut, és kiterjed az alkalmazástanúsítványokra is, például a beállítások titkosítására vagy végponttanúsítványokra. Az ACLing a bemutató szabályait követi, ezért fontos szem előtt tartani, hogy az ujjlenyomattal deklarált és az azt követő fürtkonfigurációs frissítés nélkül automatikusan visszaadó tanúsítványok elérhetetlenek lesznek.

Tanúsítvány rotálása

Megjegyzés:

Az Internet Engineering Task Force (IETF) RFC 3647 formálisan úgy határozza meg a megújítást , mint a lecserélt tanúsítványéval azonos attribútumokkal rendelkező tanúsítvány kiállítását. A kibocsátó, a tulajdonos nyilvános kulcsa és az információk megmaradnak. Az újrakulcsolás egy új kulcspárt tartalmazó tanúsítvány kiállítása, amely nem korlátozza, hogy a kiállító változhat-e. Mivel a megkülönböztetés fontos lehet (fontolja meg a tulajdonos közös neve és a kiállítói rögzítés által deklarált tanúsítványok esetét), ez a cikk a semleges kifejezésváltást használja mindkét forgatókönyv lefedésére. Ne feledje, hogy a megújítás informális használata esetén az újrakulcsolásra vonatkozik.

Ahogy korábban említettük, a Key Vault támogatja az automatikus tanúsítványforgatást. Ez azt jelzi, hogy a társított tanúsítványházirend határozza meg azt az időpontot, amely a lejárat előtt napokkal vagy a teljes élettartam százalékos értékével történik, amikor a tanúsítványt a kulcstartóban forgatják. A kiépítési ügynököt ezen időpont után, a most már meglévő tanúsítvány lejárata előtt kell meghívni, hogy az új tanúsítványt a fürt összes csomópontjára eloszthassa.

A Service Fabric segítséget nyújt ebben a folyamatban azáltal, hogy állapotjelzéseket ad, ha a fürtben jelenleg használatban lévő tanúsítvány lejárati dátuma egy előre meghatározott időköznél hamarabb következik be. Egy automatikus kiépítési ügynök, a Key Vault virtuálisgép-bővítmény, amely a Key Vault-tanúsítvány megfigyelésére van konfigurálva, rendszeres időközönként lekérdezi a kulcstartót, észleli a rotációt, és lekéri és telepíti az új tanúsítványt. A virtuális gép/VMSS titkos kulcsok szolgáltatáson keresztül történő üzembe helyezéshez egy jogosult operátornak frissítenie kell a virtuális gépet/VMSS-t az új tanúsítványnak megfelelő verziójú Key Vault URI-val.

Az elforgatott tanúsítvány most már ki van építve az összes csomóponton. Most, ha feltételezzük, hogy a fürttanúsítványra alkalmazott rotációt tulajdonosi köznév deklarálta, vizsgáljuk meg a következőt:

  • A fürtön belüli és a fürtbe irányuló új kapcsolatok esetén a Service Fabric-futtatókörnyezet megkeresi és kiválasztja a legutóbb kiadott egyező tanúsítványt (a NotBefore tulajdonság legnagyobb értéke). Ez a Service Fabric-futtatókörnyezet korábbi verzióihoz való változás.

  • A meglévő kapcsolatok életben maradnak, vagy természetes módon lejárhatnak vagy más módon megszűnhetnek, és egy belső kezelő értesítést kap arról, hogy létezik egy új egyezés.

Megjegyzés:

Jelenleg a 7.2 CU4+ verziótól a Service Fabric a legnagyobb (legutóbb kiadott) NotBefore tulajdonságértékkel rendelkező tanúsítványt választja ki. A 7,2 CU4-et megelőzően a Service Fabric kiválasztotta az érvényes tanúsítványt a legnagyobb (legújabb lejárati) NotAfter értékkel.

Ez a következő fontos megfigyelésekre fordítható le:

  • A fürt vagy a üzemeltetett alkalmazások rendelkezésre állása elsőbbséget élvez a tanúsítvány elforgatásához szükséges irányelvekkel szemben. A fürt végül konvergens lesz az új tanúsítványon, de időzítési garancia nélkül. A következőkből áll:

    • Előfordulhat, hogy egy megfigyelő számára nem egyértelmű, hogy az elforgatott tanúsítvány teljesen lecserélte az elődjét. A jelenleg használt tanúsítvány azonnali cseréjének kényszerítésének egyetlen módja a gazdagépek újraindítása. Nem elegendő újraindítani a Service Fabric-csomópontokat, mert a fürt bérletkapcsolatait alkotó kernelmód-összetevők nem lesznek hatással. A virtuális gép/VMSS újraindítása a rendelkezésre állás ideiglenes elvesztését is okozhatja. Alkalmazástanúsítványok esetén elegendő csak a megfelelő alkalmazáspéldányokat újraindítani.

    • Ha olyan újrakulcsolt tanúsítványt vezet be, amely nem felel meg az érvényességi szabályoknak, az hatékonyan megszakíthatja a fürtöt. Erre a leggyakoribb példa egy váratlan kiállító esete, ahol a fürttanúsítványokat a rendszer a kiállítói rögzítéssel közös névvel deklarálja, de az elforgatott tanúsítványt egy új vagy be nem jelentett kiállító adta ki.

Tanúsítvány törlése

Jelenleg nincsenek rendelkezések az Azure-ban a tanúsítványok explicit eltávolítására. Gyakran nem triviális feladat annak meghatározása, hogy egy adott tanúsítványt használ-e egy adott időpontban. Ez az alkalmazástanúsítványok esetében nehezebb, mint a fürttanúsítványok esetében. Maga a Service Fabric nem a kiépítési ügynök, semmilyen körülmények között nem törli a felhasználó által deklarált tanúsítványt. A szabványos kiépítési mechanizmusok esetében:

  • A virtuálisgép-/VMSS-titkos kulcsként deklarált tanúsítványok mindaddig ki vannak építve, amíg a virtuálisgép-/VMSS-definíció hivatkozik rájuk, és lekérte őket a kulcstartóból. A kulcstartó titkos kulcsának vagy tanúsítványának törlése sikertelen lesz a következő virtuálisgép-/VMSS-telepítések során. Hasonlóképpen, ha letilt egy titkos verziót a kulcstartóban, akkor a titkos verzióra hivatkozó virtuálisgép-/VMSS-telepítések is meghiúsulnak.

  • Előfordulhat, hogy a Key Vault virtuálisgép-bővítményen keresztül kiépített tanúsítványok korábbi verziói virtuálisgép-/VMSS-csomóponton találhatók vagy nem. Az ügynök csak az aktuális verziót kéri le és telepíti, és nem távolít el tanúsítványokat. Havonta újraképez egy csomópontot, amely általában minden hónapban megtörténik, alaphelyzetbe állítja a tanúsítványtárolót az operációs rendszer lemezképének tartalmára, így a korábbi verziók implicit módon törlődnek. Fontolja meg azonban, hogy egy virtuálisgép-méretezési csoport vertikális felskálázása csak a megfigyelt tanúsítványok jelenlegi verzióját fogja eredményezni. Ne feltételezze a csomópontok homogenitását a telepített tanúsítványok tekintetében.

A felügyelet egyszerűsítése: Példa az automatikus regisztrációra

Ez a cikk eddig mechanizmusokat és korlátozásokat ismertet, bonyolult szabályokat és definíciókat vázolt fel, és szörnyű előrejelzéseket készített a kimaradásokról. Most itt az ideje, hogy beállítsa az automatikus tanúsítványkezelést, hogy elkerülje ezeket a problémákat. Tegyük ezt meg egy szolgáltatásként nyújtott platformon (PaaS) v2 virtuálisgép-méretezési csoporton futó Azure Service Fabric-fürt kontextusában, a Key Vault használatával a titkos kódok kezeléséhez és a felügyelt identitások kihasználásához, az alábbiak szerint:

  • A tanúsítványok érvényesítése az ujjlenyomat-rögzítésről a tulajdonosi + kiállítói rögzítésre módosul. Az adott kiállítótól származó, adott tulajdonossal rendelkező tanúsítványok egyaránt megbízhatók.
  • A tanúsítványokat egy megbízható tárolóba (Key Vault) regisztrálják és szerezik be, és egy ügynök frissíti (itt a Key Vault virtuálisgép-bővítmény).
  • A tanúsítványok kiépítése az üzembe helyezési időről és a verzióalapúról (az Azure Számítási erőforrás-szolgáltató által végzett) verzióalapúról az üzembe helyezés utáni állapotra változik a Verzió nélküli Key Vault URI-k használatával.
  • A kulcstartóhoz való hozzáférést a felhasználó által hozzárendelt felügyelt identitások biztosítják, amelyek az üzembe helyezés során jönnek létre és vannak hozzárendelve a virtuálisgép-méretezési csoporthoz.
  • Az üzembe helyezés után az ügynök (a Key Vault virtuálisgép-bővítmény) lekérdezi és frissíti a megfigyelt tanúsítványokat a virtuálisgép-méretezési csoport minden csomópontján. A tanúsítvány rotálása így teljesen automatizált, mert a Service Fabric automatikusan felveszi a legújabb érvényes tanúsítványt.

A sorozat teljes mértékben szkriptelhető és automatizált, és lehetővé teszi a tanúsítvány automatikus regisztrációjára konfigurált fürt érintésmentes kezdeti üzembe helyezését. A következő szakaszok részletes lépéseket tartalmaznak, amelyek PowerShell-parancsmagok és JSON-sablonok töredékeinek kombinációját tartalmazzák. Ugyanez a funkció elérhető az Azure-ral való interakció minden támogatott eszközével.

Megjegyzés:

Ez a példa feltételezi, hogy egy tanúsítvány már létezik a kulcstartóban. A Key Vault által felügyelt tanúsítványok regisztrálásához és megújításához előfeltételként szükséges manuális lépések elvégzése, a cikk korábbi részében leírtak szerint. Éles környezetekben használja a Key Vault által felügyelt tanúsítványokat. Tartalmaztunk egy microsoftos belső PKI-re jellemző példaszkriptet.

Megjegyzés:

A tanúsítvány automatikus regisztrációja csak a hitelesítésszolgáltató által kibocsátott tanúsítványok esetében értelmezhető. Az önaláírt tanúsítványok használata, beleértve a Service Fabric-fürt Azure Portalon történő telepítése során létrehozott tanúsítványokat is, nem etikátlan, de helyi vagy fejlesztő által üzemeltetett üzemelő példányok esetén is lehetséges, ha a kiállító ujjlenyomatát a levéltanúsítványéval megegyezőnek nyilvánítja.

Kiindulópont

A rövidség kedvéért tegyük fel a következő kiindulási állapotot:

  • A Service Fabric-fürt létezik, és ujjlenyomattal deklarált hitelesítésszolgáltatói tanúsítvánnyal van védve.
  • A tanúsítvány egy kulcstartóban van tárolva, és virtuálisgép-méretezési csoport titkos kódjaként van kiépítve.
  • A rendszer ugyanezt a tanúsítványt használja a fürt általános névalapú tanúsítványdeklarációkká alakításához, így azt a tulajdonos és a kiállító is érvényesítheti. Ha nem ez a helyzet, szerezze be az erre a célra létrehozott hitelesítésszolgáltató által kiadott tanúsítványt, és adja hozzá a fürtdefinícióhoz ujjlenyomattal. Ezt a folyamatot a Service Fabric-fürt tanúsítványainak hozzáadása vagy eltávolítása az Azure-ban című cikkben ismertetheti.

Íme egy JSON-részlet egy ilyen állapotnak megfelelő sablonból. A részlet kihagy számos szükséges beállítást, és csak a tanúsítványokkal kapcsolatos szempontokat szemlélteti.

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

Az előző kód lényegében azt mondja, hogy a Key Vault URI-ben json [parameters('clusterCertificateUrlValue')] található ujjlenyomattal json [parameters('primaryClusterCertificateTP')] rendelkező tanúsítvány ujjlenyomattal deklarálva van a fürt egyetlen tanúsítványaként, ujjlenyomattal.

Ezután állítsuk be a tanúsítvány automatikus igényléséhez szükséges további erőforrásokat.

Az előfeltétel-erőforrások beállítása

Ahogy korábban említettük, a virtuálisgép-méretezési csoport titkos kulcsaként kiépített tanúsítványt a Microsoft számítási erőforrás-szolgáltató szolgáltatása kéri le a kulcstartóból. Ezt úgy teszi, hogy az üzembehelyezési operátor nevében használja az első fél identitását. Ez a folyamat megváltozik az automatikus regisztrációhoz. A virtuálisgép-méretezési csoporthoz hozzárendelt felügyelt identitás használatára vált, amely get engedélyekkel rendelkezik a tároló titkos kulcsaihoz.

A következő részleteket egyszerre kell üzembe helyeznie. Ezek csak a játékonkénti elemzéshez és magyarázathoz vannak külön felsorolva.

Először definiáljon egy felhasználó által hozzárendelt identitást (az alapértelmezett értékek példákként szerepelnek). További információkért tekintse meg a hivatalos dokumentációt.

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

Ezután adjon hozzáférést az identitásnak a kulcstartó titkos kulcsaihoz. A legfrissebb információkért tekintse meg a hivatalos dokumentációt.

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

A következő lépésben a következőket fogja elvégezni:

  • Rendelje hozzá a felhasználó által hozzárendelt identitást a virtuálisgép-méretezési csoporthoz.
  • Deklarálja a virtuálisgép-méretezési csoport függőségét a felügyelt identitás létrehozásától és a kulcstartóhoz való hozzáférés biztosításának eredményétől.
  • Deklarálja a Key Vault virtuálisgép-bővítményt, és kérje meg, hogy az indításkor lekérje a megfigyelt tanúsítványokat. További információkért tekintse meg a Windows hivatalos dokumentációjának Key Vault virtuálisgép-bővítményét.
  • Frissítse a Service Fabric virtuálisgép-bővítmény definícióját a Key Vault virtuálisgép-bővítményétől függően, és alakítsa át a fürttanúsítvány-deklarációt ujjlenyomatról köznapi névre.

Megjegyzés:

Ezeket a módosításokat egyetlen lépésben hajtják végre, mert ugyanazon erőforrás hatókörébe tartoznak.

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

Bár ez nem szerepel explicit módon az előző kódban, vegye figyelembe, hogy a kulcstartó tanúsítványÁNAK URL-címe el lett távolítva a OsProfile virtuálisgép-méretezési csoport szakaszából.

Az utolsó lépés a fürtdefiníció frissítése, hogy a tanúsítványdeklarációt az ujjlenyomatról a köznapi névre módosítsa. A kiállító ujjlenyomatait is rögzítjük:

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

Ezen a ponton egyetlen üzembe helyezésben futtathatja a korábban említett frissítéseket. A Service Fabric erőforrás-szolgáltató szolgáltatás a fürtfrissítést több lépésben osztja fel, ahogyan az a fürttanúsítványok ujjlenyomatból köznapi névvé alakításának szegmensében olvasható.

Elemzések és megfigyelések

Ez a szakasz a cikk során bemutatott fogalmak és folyamatok magyarázatára, valamint bizonyos fontos szempontokra való figyelemfelhívásra szolgál.

Tudnivalók a tanúsítványkiépítésről

A Key Vault virtuálisgép-bővítmény kiépítési ügynökként folyamatosan, előre meghatározott gyakorisággal fut. Ha nem tudja lekérni a megfigyelt tanúsítványt, a következő sorba lép, majd hibernál a következő ciklusig. A Service Fabric virtuálisgép-bővítménynek, mint a fürt rendszerindítási ügynökének szüksége van a deklarált tanúsítványokra, mielőtt a fürt létre tud alakulni. Ez viszont azt jelenti, hogy a Service Fabric virtuálisgép-bővítmény csak a fürttanúsítványok sikeres lekérése után futtatható, amelyet itt a json "provisionAfterExtensions" : [ "KVVMExtension" ]" záradék és a Key Vault virtuálisgép-bővítmény json "requireInitialSync": true beállítása jelöl.

Ez azt jelzi a Key Vault virtuálisgép-bővítménynek, hogy az első futtatáskor (az üzembe helyezés vagy újraindítás után) végig kell haladnia a megfigyelt tanúsítványokon, amíg az összes sikeresen le nem töltődik. Ha ezt a paramétert hamis értékre állítja, a fürttanúsítványok lekérésének sikertelenségével együtt a fürt üzembe helyezése meghiúsul. Ezzel szemben a megfigyelt tanúsítványok helytelen vagy érvénytelen listájával való kezdeti szinkronizálás megkövetelése a Key Vault virtuálisgép-bővítmény meghibásodását, és ismét a fürt üzembe helyezésének meghiúsulását eredményezné.

Tanúsítvány csatolása, magyarázat

Előfordulhat, hogy észrevette a Key Vault virtuálisgép-bővítményjelzőt linkOnRenewal , és azt a tényt, hogy hamis értékre van állítva. Ez a beállítás foglalkozik a jelölő által szabályozott viselkedéssel, valamint a fürt működésére gyakorolt hatásával. Ez a viselkedés a Windowsra jellemző.

Definíciója szerint:

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

A TLS-kapcsolat létrehozásához használt tanúsítványok általában leíróként vannak beszerezve az S-csatorna biztonsági támogatási szolgáltatóján keresztül. Vagyis az ügyfél nem fér hozzá közvetlenül a tanúsítvány titkos kulcsához. Az S-csatorna támogatja a hitelesítő adatok átirányítását vagy csatolását tanúsítványbővítmény formájában, CERT_RENEWAL_PROP_ID.

Ha ez a tulajdonság be van állítva, az értéke a megújítási tanúsítvány ujjlenyomatát jelöli, ezért az S-csatorna ehelyett megkísérli betölteni a csatolt tanúsítványt. Valójában az S-csatorna ezt a csatolt és remélhetőleg aciklikus listát fogja átvezetni, amíg a végleges tanúsítványhoz nem kerül, egy megújítási jel nélkül. Ez a funkció, ha megbízhatóan használják, nagy kockázatcsökkentést jelent a rendelkezésre állás elvesztésével szemben, amelyet például lejárt tanúsítványok okoznak.

Más esetekben ez lehet az oka a kimaradásoknak, amelyeket nehéz diagnosztizálni és enyhíteni. Az S-channel feltétel nélkül hajtja végre a tanúsítványok bejárását a megújítási tulajdonságaikon, függetlenül attól, hogy az ügyfél milyen tulajdonosi, kiállítói vagy egyéb konkrét attribútumokat vesz részt az eredményül kapott tanúsítvány ügyfél általi érvényesítésében. Lehetséges, hogy az eredményül kapott tanúsítvány nem rendelkezik társított titkos kulccsal, vagy hogy a kulcs nem lett ACLed a leendő fogyasztó számára.

Ha a csatolás engedélyezve van, a Key Vault virtuálisgép-bővítmény, amikor egy megfigyelt tanúsítványt kér le a kulcstartóból, megkísérli megkeresni az egyező, meglévő tanúsítványokat, amelyek összekapcsolják őket a megújítási bővítmény tulajdonságán keresztül. Az egyeztetés kizárólag a tulajdonos alternatív nevén (SAN) alapul, és működik, ha két meglévő tanúsítvány létezik, ahogyan az alábbi példákban is látható: A: Tanúsítvány neve (CN) = "Alice tartozékai", SAN = {"alice.universalexports.com"}, megújítás = '' B: CN = "Bob bitek", SAN = {"bob.universalexports.com", "bob.universalexports.net"}, renewal = ''

Tegyük fel, hogy egy C tanúsítványt a Key Vault virtuálisgép-bővítménye kér le: CN = "Mallory kártevője", SAN = {"alice.universalexports.com", "bob.universalexports.com", "mallory.universalexports.com"}

Az A tanúsítvány SAN-listája teljes mértékben szerepel a C-ben, így az A.renewal = C.thumbprint. A B tanúsítvány SAN-listája a C-vel közös metszettel rendelkezik, de nem szerepel benne teljesen, így a B.megújítás üres marad.

Az "A" tanúsítványon az ebben az állapotban lévő AcquireCredentialsHandle (S-channel) meghívására tett kísérletek ténylegesen C-t küldenek a távoli félnek. A Service Fabric esetében a fürt átviteli alrendszere S-csatornát használ a kölcsönös hitelesítéshez, így a korábban leírt viselkedés közvetlenül befolyásolja a fürt alapvető kommunikációját. Az előző példával folytatva, és feltételezve, hogy az A a fürttanúsítvány, a következő lépés a következőktől függ:

  • Ha C titkos kulcsa nem ACLed ahhoz a fiókhoz, amelyen a Service Fabric fut, a titkos kulcs (Standard kiadásC_E_UNKNOWN_CREDENTIALS vagy hasonló) beszerzésének sikertelensége jelenik meg.
  • Ha C titkos kulcsa elérhető, a többi csomópont (CertificateNotMatched, jogosulatlan stb.) által visszaadott engedélyezési hibákat fogja látni.

Az átvitel mindkét esetben meghiúsul, és a fürt leállhat. A tünetek eltérőek. A dolgok rosszabbá tétele érdekében a csatolás a megújítás sorrendjétől függ, amelyet a Key Vault virtuálisgép-bővítmény megfigyelt tanúsítványainak listájának sorrendje, a kulcstartó megújítási ütemezése vagy akár átmeneti hibák határoznak meg, amelyek megváltoztatják a lekérés sorrendjét.

Az ilyen incidensek elhárításához a következőket javasoljuk:

  • Ne keverje a különböző tárolótanúsítványok tulajdonos alternatív neveit. Minden tárolótanúsítványnak külön célt kell szolgálnia, és a tulajdonosának és a SAN-nak ezt a sajátosságot kell tükröznie.

  • Adja meg a tulajdonos közös nevét a SAN-listában (például szó szerint). CN=<subject common name>

  • Ha nem biztos a folytatásban, tiltsa le a megújítás csatolását a Key Vault virtuálisgép-bővítményével kiépített tanúsítványok esetében.

    Megjegyzés:

    A csatolás letiltása a Key Vault virtuálisgép-bővítmény legfelső szintű tulajdonsága, és nem állítható be az egyes megfigyelt tanúsítványokhoz.

Miért érdemes felhasználó által hozzárendelt felügyelt identitást használni? Milyen következményekkel jár a használata?

Amint az az előző JSON-kódrészletekből nyilvánvalóvá vált, a műveletek és frissítések külön szekvenálására van szükség az átalakítás sikeressége és a fürt rendelkezésre állásának fenntartása érdekében. Pontosabban a virtuálisgép-méretezési csoport erőforrása deklarálja és használja az identitását a titkos kódok lekérésére (a felhasználó szemszögéből) egyetlen frissítésben.

A Service Fabric virtuálisgép-bővítmény, amely elindítja a fürtöt, a Key Vault virtuálisgép-bővítmény befejezésétől függ, ami viszont a megfigyelt tanúsítványok sikeres lekérésétől függ.

A Key Vault virtuálisgép-bővítmény a virtuálisgép-méretezési csoport identitását használja a kulcstartó eléréséhez, ami azt jelenti, hogy a kulcstartó hozzáférési szabályzatának már frissítenie kell a virtuálisgép-méretezési csoport üzembe helyezése előtt.

Egy felügyelt identitás létrehozásához vagy egy másik erőforráshoz való hozzárendeléséhez az üzembe helyezési operátornak rendelkeznie kell az előfizetésben vagy az erőforráscsoportban a szükséges szerepkörrel (ManagedIdentityOperator) a sablonban hivatkozott egyéb erőforrások kezeléséhez szükséges szerepkörök mellett.

Biztonsági szempontból ne feledje, hogy a virtuálisgép-méretezési csoport az Azure-identitás tekintetében biztonsági határnak minősül. Ez azt jelenti, hogy a virtuális gépen üzemeltetett alkalmazások elvileg beszerezhetnek egy, a virtuális gépet képviselő hozzáférési jogkivonatot. A felügyelt identitás-hozzáférési jogkivonatok a hitelesítés nélküli példány metaadat-szolgáltatásvégpontjáról szerezhetők be. Ha a virtuális gépet megosztott vagy több-bérlős környezetnek tekinti, előfordulhat, hogy a fürttanúsítványok lekérésének ez a módszere nem jelenik meg. Ez azonban az egyetlen olyan kiépítési mechanizmus, amely alkalmas a tanúsítványok automatikus igénylésére.

Hibaelhárítás és gyakori kérdések

K: Hogyan regisztrálhatok programozott módon egy Key Vault által felügyelt tanúsítványba?

Keresse meg a kiállító nevét a Key Vault dokumentációjában, majd cserélje le a következő szkriptben:

  $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

K: Mi történik, ha egy tanúsítványt be nem jelentett vagy nem meghatározott kiállító állít ki? Hol szerezhetem be egy adott PKI aktív kiállítóinak teljes listáját?

Ha a tanúsítványdeklaráció kiállítói ujjlenyomatokat ad meg, és a tanúsítvány közvetlen kiállítója nem szerepel a rögzített kiállítók listájában, a tanúsítvány érvénytelennek minősül, függetlenül attól, hogy az ügyfél megbízható-e a gyökerében. Ezért kritikus fontosságú annak biztosítása, hogy a kiállítók listája naprakész legyen. Az új kiállító bevezetése ritka esemény, és széles körben közzé kell tenni, mielőtt megkezdené a tanúsítványok kiállítását.

A PKI általában az IETF RFC 7382-nek megfelelően közzéteszi és fenntartja a tanúsítási gyakorlatra vonatkozó nyilatkozatot. Az egyéb információk mellett az utasítás az összes aktív kiállítót is tartalmazza. A lista programozott beolvasása eltérhet az egyik PKI-től a másikig.

A Microsoft-belső PKI-k esetében mindenképpen tekintse meg az engedélyezett kiállítók lekéréséhez használt végpontok és SDK-k belső dokumentációját. A fürttulajdonos feladata, hogy rendszeres időközönként tekintse át ezt a listát annak biztosítása érdekében, hogy a fürtdefiníciója tartalmazza az összes várt kiállítót.

K: Több PKI támogatott?

Igen. A fürtjegyzékben nem deklarálhat több, azonos értékkel rendelkező CN-bejegyzést, de több, ugyanazon CN-nek megfelelő PKI-k kiállítóit is listázhatja. Ez nem ajánlott eljárás, és a tanúsítványátlátványozási eljárások megakadályozhatják az ilyen tanúsítványok kiállítását. Ez azonban egy elfogadható mechanizmus, amely az egyik PKI-ből a másikba való migrálást jelenti.

K: Mi a teendő, ha az aktuális fürttanúsítvány nem ca-kiadású, vagy nem rendelkezik a kívánt tulajdonosával?

Szerezze be a kívánt tulajdonossal rendelkező tanúsítványt, és adja hozzá a fürt definíciójához másodlagosként, ujjlenyomattal. A frissítés sikeres befejezése után kezdeményezze a fürtkonfiguráció újabb frissítését a tanúsítványdeklaráció köznapi névvé alakításához.