Zarządzanie certyfikatami w klastrach usługi Service Fabric

W tym artykule opisano aspekty zarządzania certyfikatami używanymi do zabezpieczania komunikacji w klastrach usługi Azure Service Fabric. Uzupełnia wprowadzenie do zabezpieczeń klastra usługi Service Fabric oraz objaśnienie uwierzytelniania opartego na certyfikatach X.509 w usłudze Service Fabric.

Wymagania wstępne

Przed rozpoczęciem należy zapoznać się z podstawowymi pojęciami dotyczącymi zabezpieczeń i mechanizmami kontroli udostępnianymi przez usługę Service Fabric w celu skonfigurowania zabezpieczeń klastra.

Zastrzeżenie

W tym artykule przedstawiono teoretyczne aspekty zarządzania certyfikatami z praktycznymi przykładami obejmującymi specyfikę usług, technologii itd. Ponieważ większość odbiorców w tym miejscu jest wewnętrzna firma Microsoft, artykuł odnosi się do usług, technologii i produktów specyficznych dla platformy Azure. Jeśli niektóre szczegóły specyficzne dla firmy Microsoft nie mają zastosowania do Ciebie, możesz poprosić o wyjaśnienie lub wskazówki w sekcji komentarzy na końcu.

Definiowanie zarządzania certyfikatami

Jak dowiesz się w artykule towarzyszącym X.509 uwierzytelnianie oparte na certyfikatach w klastrach usługi Service Fabric, certyfikat jest obiektem kryptograficznym, który zasadniczo wiąże parę kluczy asymetrycznych z atrybutami, które opisują reprezentowaną przez nią jednostkę.

Jednak certyfikat jest również nietrwałym obiektem, ponieważ jego okres istnienia jest skończony i jest podatny na naruszenie. Przypadkowe ujawnienie lub pomyślne wykorzystanie luk w zabezpieczeniach może spowodować, że certyfikat będzie bezużyteczny z punktu widzenia zabezpieczeń. Ta cecha oznacza konieczność rutynowej zmiany certyfikatów lub w odpowiedzi na zdarzenie zabezpieczeń.

Innym aspektem zarządzania certyfikatami i całkowicie oddzielnym tematem jest ochrona kluczy prywatnych certyfikatów lub wpisów tajnych, które chronią tożsamości jednostek zaangażowanych w pozyskiwanie i aprowizowanie certyfikatów.

Opisujemy zarządzanie certyfikatami jako procesy i procedury używane do uzyskiwania certyfikatów oraz bezpiecznego transportu ich do miejsca, w którym są potrzebne.

Niektóre operacje zarządzania, takie jak rejestracja, ustawienie zasad i kontrolki autoryzacji, wykraczają poza zakres tego artykułu. Inne operacje, takie jak aprowizowanie, odnawianie, ponowne tworzenie kluczy lub odwoływanie, są powiązane tylko przypadkowo z usługą Service Fabric. Niemniej jednak artykuł nieco je rozwiązuje, ponieważ zrozumienie tych operacji może pomóc w prawidłowym zabezpieczeniu klastra.

Twoim bezpośrednim celem może być zautomatyzowanie zarządzania certyfikatami tak bardzo, jak to możliwe, aby zapewnić nieprzerwaną dostępność klastra. Ponieważ proces jest bezpłatny dla użytkownika, warto również oferować zabezpieczenia. Dzięki klastrom usługi Service Fabric ten cel jest osiągalny.

Pozostała część artykułu najpierw dekonstrukuje zarządzanie certyfikatami, a później koncentruje się na włączaniu autorollowania.

W szczególności opisano w nim następujące tematy:

• Założenia dotyczące rozdzielenia autorstwa między właścicielem a platformą
• Długi potok od wystawiania certyfikatów do użycia
• Rotacja certyfikatów: dlaczego, jak i kiedy
• Co może pójść nie tak?

Artykuł nie obejmuje następujących tematów:

• Zabezpieczanie nazw domen i zarządzanie nimi
• Rejestrowanie w certyfikatach
• Konfigurowanie kontrolek autoryzacji w celu wymuszania wystawiania certyfikatów.

Aby uzyskać informacje na temat tych tematów, zapoznaj się z urzędem rejestracji (RA) ulubionej usługi infrastruktury kluczy publicznych (PKI). Jeśli jesteś czytelnikiem wewnętrznym firmy Microsoft, możesz skontaktować się z usługą Azure Security.

Role i jednostki związane z zarządzaniem certyfikatami

Podejście do zabezpieczeń w klastrze usługi Service Fabric jest przypadkiem "właściciel klastra deklaruje go, środowisko uruchomieniowe usługi Service Fabric je wymusza". Oznacza to, że prawie żaden z certyfikatów, kluczy lub innych poświadczeń tożsamości, które uczestniczą w funkcjonowania klastra, pochodzą z samej usługi. Wszystkie są deklarowane przez właściciela klastra. Właściciel klastra jest również odpowiedzialny za aprowizowanie certyfikatów w klastrze, odnawianie ich zgodnie z potrzebami i zapewnianie bezpieczeństwa przez cały czas.

W szczególności właściciel klastra musi upewnić się, że:

• Certyfikaty zadeklarowane w sekcji NodeType manifestu klastra można znaleźć w każdym węźle tego typu zgodnie z regułami prezentacji.
• Certyfikaty zadeklarowane jako w poprzednim punkcie punktora są instalowane z dołączonymi odpowiednimi kluczami prywatnymi.
• Certyfikaty zadeklarowane w regułach prezentacji powinny przekazywać reguły sprawdzania poprawności.

Usługa Service Fabric, ze swej strony, przyjmuje następujące obowiązki:

• Lokalizowanie certyfikatów pasujących do deklaracji w definicji klastra
• Udzielanie dostępu do odpowiednich kluczy prywatnych dla jednostek kontrolowanych przez usługę Service Fabric na podstawie potrzeb
• Weryfikowanie certyfikatów zgodnie z ustalonymi najlepszymi rozwiązaniami dotyczącymi zabezpieczeń i definicją klastra
• Zgłaszanie alertów dotyczących zbliżającego się wygaśnięcia certyfikatów lub niepowodzeń w celu wykonania podstawowych kroków weryfikacji certyfikatu
• Weryfikowanie (do pewnego stopnia), że aspekty związane z certyfikatem definicji klastra są spełnione przez podstawową konfigurację hostów

Wynika z tego, że obciążenie związane z zarządzaniem certyfikatami (jako aktywne operacje) spada wyłącznie na właściciela klastra. W następnych sekcjach przyjrzymy się bliżej poszczególnym operacjom zarządzania, w tym dostępnym mechanizmom i ich wpływowi na klaster.

Podróż certyfikatu

Szybko przedstawimy postęp wystawiania certyfikatu do użycia w kontekście klastra usługi Service Fabric:

1. Właściciel domeny rejestruje się w urzędzie rejestrowania infrastruktury kluczy publicznych domeny lub podmiotu, który chce skojarzyć z certyfikatami. Certyfikaty z kolei stanowią dowód własności domeny lub podmiotu.

2. Właściciel domeny określa również w urzędzie rejestrowania tożsamości autoryzowanych osób żądających, jednostek uprawnionych do żądania rejestracji certyfikatów z określoną domeną lub podmiotem.

3. Autoryzowany osoba żądający następnie rejestruje się w certyfikacie za pośrednictwem usługi zarządzania wpisami tajnymi. Na platformie Azure wybrana usługa zarządzania wpisami tajnymi to Azure Key Vault, która bezpiecznie przechowuje i umożliwia pobieranie wpisów tajnych i certyfikatów przez autoryzowane jednostki. Usługa Key Vault odnawia również i ponownie klucze certyfikatu zgodnie z konfiguracją w skojarzonych zasadach certyfikatu. Usługa Key Vault używa identyfikatora Entra firmy Microsoft jako dostawcy tożsamości.

4. Autoryzowany moduł pobierania lub agent aprowizacji pobiera certyfikat z magazynu kluczy, w tym jego klucz prywatny, i instaluje go na maszynach hostujących klaster.

5. Usługa Service Fabric (uruchomiona z podwyższonym poziomem uprawnień w każdym węźle) przyznaje dostęp do dozwolonych jednostek usługi Service Fabric, które są wyznaczone przez grupy lokalne i podzielone między serviceFabricAdministrators i ServiceFabricAllowedUsers.

6. Środowisko uruchomieniowe usługi Service Fabric uzyskuje dostęp do certyfikatu i używa go do ustanowienia federacji lub uwierzytelniania żądań przychodzących od autoryzowanych klientów.

7. Agent aprowizacji monitoruje certyfikat magazynu kluczy, a po wykryciu odnowienia wyzwala przepływ aprowizacji. Właściciel klastra aktualizuje definicję klastra, jeśli jest to konieczne, aby wskazać zamiar przerzucania certyfikatu.

8. Agent aprowizacji lub właściciel klastra jest również odpowiedzialny za czyszczenie i usuwanie nieużywanych certyfikatów.

Na potrzeby tego artykułu pierwsze dwa kroki w poprzedniej sekwencji są w większości niepowiązane. Jedynym połączeniem jest to, że nazwa pospolita podmiotu certyfikatu to nazwa DNS zadeklarowana w definicji klastra.

Przepływ wystawiania i aprowizacji certyfikatów przedstawiono na następujących diagramach:

W przypadku certyfikatów zadeklarowanych za pomocą odcisku palca

W przypadku certyfikatów zadeklarowanych przez nazwę pospolitą podmiotu

Rejestracja certyfikatu

Temat rejestracji certyfikatów został szczegółowo omówiony w dokumentacji usługi Key Vault. W tym miejscu znajduje się streszczenie zapewniające ciągłość i łatwiejsze odwołanie.

Kontynuując korzystanie z platformy Azure jako kontekstu i korzystając z usługi Key Vault jako usługi zarządzania wpisami tajnymi, autoryzowany osoba żądającą certyfikatów musi mieć co najmniej uprawnienia do zarządzania certyfikatami w magazynie kluczy przyznane przez właściciela magazynu kluczy. Następnie żądający rejestruje się w certyfikacie w następujący sposób:

• Żądający tworzy zasady certyfikatów w usłudze Key Vault, które określają domenę/podmiot certyfikatu, żądanego wystawcę, typ klucza i długość, zamierzone użycie klucza i nie tylko. Aby uzyskać więcej informacji, zobacz Certyfikaty w usłudze Azure Key Vault.

• Obiekt żądający tworzy certyfikat w tym samym magazynie z zasadami określonymi w poprzednim kroku. To z kolei generuje parę kluczy jako obiekty magazynu i żądanie podpisania certyfikatu podpisane przy użyciu klucza prywatnego, które jest następnie przekazywane do wyznaczonego wystawcy do podpisania.

• Po wystawcy lub urzędzie certyfikacji (CA) odpowiedzi z podpisanym certyfikatem wynik jest scalony z magazynem kluczy, a dane certyfikatu są dostępne w następujący sposób:

  • W obszarze {vaultUri}/certificates/{name}: Certyfikat, w tym klucz publiczny i metadane
  • W obszarze {vaultUri}/keys/{name}: Klucz prywatny certyfikatu dostępny dla operacji kryptograficznych (zawijanie/odpakowywanie, podpisywanie/weryfikowanie)
  • W obszarze {vaultUri}/secrets/{name}: Certyfikat, w tym jego klucz prywatny, dostępny do pobrania jako niechroniony plik PFX lub PEM.

Pamiętaj, że certyfikat w magazynie kluczy zawiera chronologiczną listę wystąpień certyfikatów, które współużytkuje zasady. Wersje certyfikatów zostaną utworzone zgodnie z atrybutami okresu istnienia i odnowienia tych zasad. Zdecydowanie zalecamy, aby certyfikaty magazynu nie współużytkować podmiotów lub domen ani nazw DNS, ponieważ może to być zakłócające w klastrze, aby aprowizować wystąpienia certyfikatów z różnych certyfikatów magazynu, z identycznymi tematami, ale znacznie różnymi innymi atrybutami, takimi jak wystawca, użycie kluczy itd. W tym momencie w magazynie kluczy istnieje certyfikat gotowy do użycia. Teraz przyjrzyjmy się pozostałej części procesu.

Aprowizowanie certyfikatów

Wspomnieliśmy o agencie aprowizacji, który jest jednostką, która pobiera certyfikat, w tym jego klucz prywatny, z magazynu kluczy i instaluje go na każdym z hostów klastra. (Przypomnij sobie, że usługa Service Fabric nie aprowizować certyfikatów).

W kontekście tego artykułu klaster będzie hostowany w kolekcji maszyn wirtualnych platformy Azure lub zestawów skalowania maszyn wirtualnych. Na platformie Azure można aprowizować certyfikat z magazynu do maszyny wirtualnej/zestawu skalowania maszyn wirtualnych przy użyciu następujących mechanizmów. Przyjęto założenie, że agent aprowizacji otrzymał wcześniej uprawnienia do uzyskiwania uprawnień do magazynu kluczy przez właściciela magazynu kluczy.

• Ad hoc: operator pobiera certyfikat z magazynu kluczy (jako PFX/PKCS #12 lub PEM) i instaluje go w każdym węźle.

  Mechanizm ad hoc nie jest zalecany, z wielu powodów, począwszy od zabezpieczeń do dostępności, i nie zostanie omówiony tutaj dalej. Aby uzyskać więcej informacji, zobacz Często zadawane pytania dotyczące zestawów skalowania maszyn wirtualnych platformy Azure.

• Jako wpis tajny zestawu skalowania maszyn wirtualnych podczas wdrażania: przy użyciu tożsamości pierwszej firmy w imieniu operatora usługa obliczeniowa pobiera certyfikat z magazynu obsługującego wdrożenie szablonu i instaluje go w każdym węźle zestawu skalowania maszyn wirtualnych zgodnie z opisem w temacie Często zadawane pytania dotyczące zestawów skalowania maszyn wirtualnych platformy Azure.

  Uwaga

  Takie podejście umożliwia aprowizowanie tylko wersji wpisów tajnych.

• Za pomocą rozszerzenia maszyny wirtualnej usługi Key Vault. Dzięki temu można aprowizować certyfikaty przy użyciu deklaracji bez wersji z okresowym odświeżaniem obserwowanych certyfikatów. W takim przypadku oczekuje się, że maszyna wirtualna/zestaw skalowania maszyn wirtualnych będzie mieć tożsamość zarządzaną , tożsamość, która uzyskała dostęp do magazynów kluczy zawierających obserwowane certyfikaty.

Aprowizowanie oparte na usłudze VMSS/obliczeniach zapewnia korzyści zabezpieczeń i dostępności, ale również zawiera ograniczenia. Wymaga, zgodnie z projektem, że certyfikaty są deklarowane jako wersjonowane wpisy tajne. To wymaganie sprawia, że aprowizacja usługi VMSS/oparta na obliczeniach jest odpowiednia tylko dla klastrów zabezpieczonych certyfikatami zadeklarowanymi przez odcisk palca.

Z kolei aprowizacja oparta na rozszerzeniu usługi Key Vault zawsze instaluje najnowszą wersję każdego obserwowanego certyfikatu. które nadaje się tylko dla klastrów zabezpieczonych certyfikatami zadeklarowanymi przez nazwę pospolitą podmiotu. Aby podkreślić, nie należy używać mechanizmu aprowizacji autorefresh (takiego jak rozszerzenie maszyny wirtualnej usługi Key Vault) dla certyfikatów zadeklarowanych przez wystąpienie (czyli odcisk palca). Ryzyko utraty dostępności jest znaczne.

Istnieją inne mechanizmy aprowizacji, ale wymienione tutaj podejścia to obecnie akceptowane opcje klastrów usługi Azure Service Fabric.

Użycie i monitorowanie certyfikatów

Jak wspomniano wcześniej, środowisko uruchomieniowe usługi Service Fabric jest odpowiedzialne za lokalizowanie i używanie certyfikatów zadeklarowanych w definicji klastra. W artykule Dotyczącym uwierzytelniania opartego na certyfikatach X.509 w klastrach usługi Service Fabric wyjaśniono szczegółowo, jak usługa Service Fabric implementuje reguły prezentacji i weryfikacji i nie zostanie ponownie omówiona w tym miejscu. W tym artykule zapoznasz się z udzielaniem dostępu i uprawnieniami, a także monitorowaniem.

Pamiętaj, że certyfikaty w usłudze Service Fabric są używane w wielu celach, od wzajemnego uwierzytelniania w warstwie federacyjnej do uwierzytelniania tls (Transport Layer Security) dla punktów końcowych zarządzania. Wymaga to dostępu do klucza prywatnego certyfikatu przez różne składniki lub usługi systemowe. Środowisko uruchomieniowe usługi Service Fabric regularnie skanuje magazyn certyfikatów, wyszukując dopasowania dla każdej ze znanych reguł prezentacji.

Dla każdego zgodnego certyfikatu znajduje się odpowiedni klucz prywatny, a jego uznaniowa lista kontroli dostępu jest aktualizowana w celu uwzględnienia uprawnień (odczyt i wykonanie, zwykle), które są przyznawane tożsamości, która ich wymaga.

Ten proces jest nieformalnie określany jako ACLing. Proces jest uruchamiany w ciągu jednej minuty, a także obejmuje certyfikaty aplikacji , takie jak te używane do szyfrowania ustawień lub jako certyfikaty punktów końcowych. Funkcja ACLing jest zgodna z regułami prezentacji, dlatego należy pamiętać, że certyfikaty zadeklarowane przez odcisk palca i które są autorefreshed bez aktualizacji konfiguracji klastra będą niedostępne.

Wymiana certyfikatów

Uwaga

Internet Engineering Task Force (IETF) RFC 3647 formalnie definiuje odnawianie jako wystawianie certyfikatu z tymi samymi atrybutami co zastępowany certyfikat. Wystawca, klucz publiczny podmiotu i informacje są zachowywane. Ponowne tworzenie kluczy to wystawianie certyfikatu z nową parą kluczy bez ograniczeń co do tego, czy wystawca może ulec zmianie. Ponieważ rozróżnienie może być ważne (należy wziąć pod uwagę przypadek certyfikatów zadeklarowanych przez nazwę pospolitą podmiotu przy przypięciu wystawcy), w tym artykule użyto neutralnej rotacji terminów w celu pokrycia obu scenariuszy. Należy pamiętać, że jeśli odnawianie jest używane nieformalnie, odnosi się do ponownego tworzenia kluczy.

Jak wspomniano wcześniej, usługa Key Vault obsługuje automatyczną rotację certyfikatów. Oznacza to, że zasady kojarzenia certyfikatu definiują punkt w czasie, niezależnie od tego, czy do dni przed wygaśnięciem, czy procentem całkowitego okresu istnienia, gdy certyfikat jest obracany w magazynie kluczy. Agent aprowizacji musi być wywoływany po tym punkcie w czasie i przed wygaśnięciem teraz poprzedniego certyfikatu, aby dystrybuować ten nowy certyfikat do wszystkich węzłów klastra.

Usługa Service Fabric pomaga w tym procesie, wywołując ostrzeżenia o kondycji, gdy data wygaśnięcia certyfikatu, który jest obecnie używany w klastrze, występuje wcześniej niż określony interwał. Agent automatycznej aprowizacji, rozszerzenie maszyny wirtualnej usługi Key Vault skonfigurowane do obserwowania certyfikatu magazynu kluczy, okresowo sonduje magazyn kluczy, wykrywa rotację i pobiera i instaluje nowy certyfikat. Aprowizowanie, które odbywa się za pośrednictwem funkcji wpisów tajnych maszyny wirtualnej/zestawu skalowania maszyn wirtualnych, wymaga autoryzowanego operatora zaktualizowania zestawu VM/VMSS przy użyciu identyfikatora URI usługi Key Vault, który odpowiada nowemu certyfikatowi.

Obrócony certyfikat jest teraz aprowizowany we wszystkich węzłach. Teraz, zakładając, że rotacja zastosowana do certyfikatu klastra została zadeklarowana przez nazwę pospolitą podmiotu, sprawdźmy, co się dzieje dalej:

• W przypadku nowych połączeń w ramach klastra, a także do klastra, środowisko uruchomieniowe usługi Service Fabric znajduje i wybiera ostatnio wystawiony zgodny certyfikat (największa wartość właściwości NotBefore ). Jest to zmiana z wcześniejszych wersji środowiska uruchomieniowego usługi Service Fabric.

• Istniejące połączenia są aktywne lub mogą w naturalny sposób wygasać lub w inny sposób przerywać, a wewnętrzna procedura obsługi zostanie powiadomiona o tym, że istnieje nowe dopasowanie.

Uwaga

Obecnie od wersji 7.2 CU4 lub nowszej usługa Service Fabric wybiera certyfikat z największą (ostatnio wystawioną) wartością właściwości NotBefore . Przed 7.2 CU4 usługa Service Fabric wybrała prawidłowy certyfikat z największą (najnowszą wygasającą) wartością NotAfter .

Przekłada się to na następujące ważne obserwacje:

• Dostępność klastra lub hostowanych aplikacji ma pierwszeństwo przed dyrektywą w celu rotacji certyfikatu. Klaster będzie w końcu zbieżny z nowym certyfikatem, ale bez gwarancji czasu. W następujący sposób:

  • Nie może być od razu oczywiste dla obserwatora, że obrócony certyfikat całkowicie zastąpił swojego poprzednika. Jedynym sposobem wymuszenia natychmiastowego zastąpienia używanego certyfikatu jest ponowne uruchomienie maszyn hosta. Nie wystarczy ponownie uruchomić węzły usługi Service Fabric, ponieważ składniki trybu jądra, które tworzą połączenia dzierżawy w klastrze, nie będą miały wpływu. Ponadto ponowne uruchomienie maszyny wirtualnej/zestawu skalowania maszyn wirtualnych może spowodować tymczasową utratę dostępności. W przypadku certyfikatów aplikacji wystarczy ponownie uruchomić tylko odpowiednie wystąpienia aplikacji.

  • Wprowadzenie ponownie klucza certyfikatu, który nie spełnia reguł walidacji, może skutecznie przerwać klaster. Najczęstszym przykładem jest nieoczekiwany wystawca, w którym certyfikaty klastra są deklarowane przez nazwę pospolitą podmiotu z przypięciem wystawcy, ale obrócony certyfikat został wystawiony przez nowego lub niezadeklarowanego wystawcę.

Oczyszczanie certyfikatu

Obecnie na platformie Azure nie ma żadnych przepisów dotyczących jawnego usuwania certyfikatów. Często jest to zadanie nietrygalne w celu określenia, czy określony certyfikat jest używany w określonym czasie. Jest to trudniejsze w przypadku certyfikatów aplikacji niż w przypadku certyfikatów klastra. Sama usługa Service Fabric, nie będąc agentem aprowizacji, nie usunie certyfikatu zadeklarowanego przez użytkownika w żadnym wypadku. W przypadku standardowych mechanizmów aprowizacji:

• Certyfikaty zadeklarowane jako wpisy tajne maszyny wirtualnej/zestawu skalowania maszyn wirtualnych są aprowizowane, o ile są one przywoływane w definicji maszyny wirtualnej/zestawu skalowania maszyn wirtualnych i są możliwe do pobrania z magazynu kluczy. Usunięcie wpisu tajnego lub certyfikatu magazynu kluczy zakończy się niepowodzeniem po kolejnych wdrożeniach maszyn wirtualnych/zestawów skalowania maszyn wirtualnych. Podobnie wyłączenie wersji wpisu tajnego w magazynie kluczy spowoduje również niepowodzenie wdrożeń maszyn wirtualnych/zestawów skalowania maszyn wirtualnych, które odwołują się do wersji wpisu tajnego.

• Wcześniejsze wersje certyfikatów aprowizowania za pośrednictwem rozszerzenia maszyny wirtualnej usługi Key Vault mogą lub nie są obecne w węźle vm/VMSS. Agent pobiera i instaluje tylko bieżącą wersję i nie usuwa żadnych certyfikatów. Ponowne tworzenie obrazu węzła, który zwykle występuje co miesiąc, resetuje magazyn certyfikatów do zawartości obrazu systemu operacyjnego, dlatego wcześniejsze wersje zostaną niejawnie usunięte. Należy jednak rozważyć, że skalowanie w górę zestawu skalowania maszyn wirtualnych spowoduje zainstalowanie tylko bieżącej wersji obserwowanych certyfikatów. Nie zakładaj jednorodności węzłów w odniesieniu do zainstalowanych certyfikatów.

Upraszczanie zarządzania: przykład automatycznego wyrejestrowania

Do tej pory w tym artykule opisano mechanizmy i ograniczenia, opisano skomplikowane reguły i definicje oraz dokonano tragicznych przewidywań awarii. Teraz nadszedł czas, aby skonfigurować automatyczne zarządzanie certyfikatami, aby uniknąć wszystkich tych problemów. Zróbmy to w kontekście klastra usługi Azure Service Fabric uruchomionego na platformie jako usługa (PaaS) w wersji 2 zestawu skalowania maszyn wirtualnych, używając usługi Key Vault do zarządzania wpisami tajnymi i korzystania z tożsamości zarządzanych w następujący sposób:

• Walidacja certyfikatów jest zmieniana z przypinania odcisku palca do podmiotu i przypinania wystawcy. Każdy certyfikat z określonym podmiotem od określonego wystawcy jest równie zaufany.
• Certyfikaty są rejestrowane i uzyskiwane z zaufanego magazynu (Key Vault) i odświeżane przez agenta (tutaj rozszerzenie maszyny wirtualnej usługi Key Vault).
• Aprowizowanie certyfikatów jest zmieniane z czasu wdrożenia i opartego na wersji (zgodnie z operacją dostawcy zasobów obliczeniowych platformy Azure) na po wdrożeniu przy użyciu identyfikatorów URI usługi Key Vault bez wersji.
• Dostęp do magazynu kluczy jest udzielany za pośrednictwem tożsamości zarządzanych przypisanych przez użytkownika, które są tworzone i przypisywane do zestawu skalowania maszyn wirtualnych podczas wdrażania.
• Po wdrożeniu agent (rozszerzenie maszyny wirtualnej usługi Key Vault) sonduje i odświeża obserwowane certyfikaty w każdym węźle zestawu skalowania maszyn wirtualnych. Rotacja certyfikatów jest zatem w pełni zautomatyzowana, ponieważ usługa Service Fabric automatycznie pobiera najnowszy prawidłowy certyfikat.

Sekwencja jest w pełni skryptowa i zautomatyzowana i umożliwia użytkownikowi bezobsługowe początkowe wdrożenie klastra skonfigurowanego do automatycznego rejestrowania certyfikatów. W następnych sekcjach przedstawiono szczegółowe kroki, które zawierają kombinację poleceń cmdlet programu PowerShell i fragmentów szablonów JSON. Ta sama funkcja jest osiągalna ze wszystkimi obsługiwanymi metodami interakcji z platformą Azure.

Uwaga

W tym przykładzie przyjęto założenie, że certyfikat istnieje już w magazynie kluczy. Rejestrowanie i odnawianie certyfikatu zarządzanego przez usługę Key Vault wymaga wstępnie wymaganych czynności ręcznych, zgodnie z opisem we wcześniejszej sekcji tego artykułu. W przypadku środowisk produkcyjnych użyj certyfikatów zarządzanych przez usługę Key Vault. Dołączyliśmy przykładowy skrypt specyficzny dla wewnętrznej infrastruktury kluczy publicznych firmy Microsoft.

Uwaga

Automatyczne wyrejestrowanie certyfikatów ma sens tylko w przypadku certyfikatów wystawionych przez urząd certyfikacji. Używanie certyfikatów z podpisem własnym, w tym tych generowanych podczas wdrażania klastra usługi Service Fabric w witrynie Azure Portal, jest niesensowne, ale nadal jest możliwe w przypadku wdrożeń hostowanych lokalnie lub przez deweloperów, jeśli zadeklarowano odcisk palca wystawcy jako taki sam jak certyfikat liścia.

Punkt początkowy

W celu zachowania zwięzłości przyjmijmy następujący stan początkowy:

• Klaster usługi Service Fabric istnieje i jest zabezpieczony certyfikatem wystawionym przez urząd certyfikacji zadeklarowanym przez odcisk palca.
• Certyfikat jest przechowywany w magazynie kluczy i aprowizowany jako klucz tajny zestawu skalowania maszyn wirtualnych.
• Ten sam certyfikat będzie używany do konwertowania klastra na deklaracje certyfikatów opartych na nazwach pospolitych, dzięki czemu może zostać zweryfikowany przez podmiot i wystawcę. Jeśli tak nie jest, uzyskaj wystawiony przez urząd certyfikacji certyfikat przeznaczony do tego celu i dodaj go do definicji klastra według odcisku palca. Ten proces wyjaśniono w artykule Dodawanie lub usuwanie certyfikatów dla klastra usługi Service Fabric na platformie Azure.

Oto fragment kodu JSON z szablonu, który odpowiada takiemu stanowi. Fragment pomija wiele wymaganych ustawień i ilustruje tylko aspekty związane z certyfikatem.

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

Powyższy kod zasadniczo mówi, że certyfikat z odciskiem json [parameters('primaryClusterCertificateTP')] palca i znaleziony w identyfikatorze URI json [parameters('clusterCertificateUrlValue')] usługi Key Vault jest zadeklarowany jako jedyny certyfikat klastra za pomocą odcisku palca.

Następnie skonfigurujmy dodatkowe zasoby potrzebne do zapewnienia automatycznego wyrejestrowania certyfikatu.

Konfigurowanie zasobów wstępnych

Jak wspomniano wcześniej, certyfikat aprowizowany jako wpis tajny zestawu skalowania maszyn wirtualnych jest pobierany z magazynu kluczy przez usługę Microsoft Compute Resource Provider. Robi to przy użyciu tożsamości pierwszej firmy w imieniu operatora wdrażania. Ten proces zmieni się w przypadku automatycznego wyrejestrowania. Przełączysz się na użycie tożsamości zarządzanej przypisanej do zestawu skalowania maszyn wirtualnych i udzielono uprawnień GET do wpisów tajnych w tym magazynie.

Następne fragmenty należy wdrożyć w tym samym czasie. Są one wymienione indywidualnie tylko do analizy po play-by-play i wyjaśnienia.

Najpierw zdefiniuj tożsamość przypisaną przez użytkownika (wartości domyślne są uwzględniane jako przykłady). Aby uzyskać więcej informacji, zobacz oficjalną dokumentację.

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

Następnie przyznaj tej tożsamości dostęp do wpisów tajnych magazynu kluczy. Aby uzyskać najbardziej aktualne informacje, zobacz oficjalną dokumentację.

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

W następnym kroku wykonasz następujące czynności:

• Przypisz tożsamość przypisaną przez użytkownika do zestawu skalowania maszyn wirtualnych.
• Zadeklaruj zależność zestawu skalowania maszyn wirtualnych od utworzenia tożsamości zarządzanej i w wyniku udzielenia mu dostępu do magazynu kluczy.
• Zadeklaruj rozszerzenie maszyny wirtualnej usługi Key Vault i wymagaj, aby pobierał zaobserwowane certyfikaty podczas uruchamiania. Aby uzyskać więcej informacji, zobacz oficjalną dokumentację rozszerzenia maszyny wirtualnej usługi Key Vault dla systemu Windows .
• Zaktualizuj definicję rozszerzenia maszyny wirtualnej usługi Service Fabric, aby zależeć od rozszerzenia maszyny wirtualnej usługi Key Vault i przekonwertować deklarację certyfikatu klastra z odcisku palca na nazwę pospolitą.

Uwaga

Te zmiany są wprowadzane jako jeden krok, ponieważ należą one do zakresu tego samego zasobu.

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

Mimo że nie jest on jawnie wymieniony w poprzednim kodzie, należy pamiętać, że adres URL certyfikatu magazynu kluczy został usunięty z OsProfile sekcji zestawu skalowania maszyn wirtualnych.

Ostatnim krokiem jest zaktualizowanie definicji klastra w celu zmiany deklaracji certyfikatu z odcisku palca na nazwę pospolitą. Przypinamy również odciski palca wystawcy:

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

W tym momencie można uruchomić wymienione wcześniej aktualizacje w jednym wdrożeniu. W ramach tej części usługa Dostawcy zasobów usługi Service Fabric dzieli uaktualnienie klastra w kilku krokach zgodnie z opisem w segmencie konwertowania certyfikatów klastra z odcisku palca na nazwę pospolitą.

Analiza i obserwacje

Ta sekcja to omówienie pojęć i procesów, które zostały przedstawione w tym artykule, a także zwracanie uwagi na niektóre inne ważne aspekty.

Informacje o aprowizacji certyfikatów

Rozszerzenie maszyny wirtualnej usługi Key Vault jako agent aprowizacji jest uruchamiane w sposób ciągły z wcześniej określoną częstotliwością. Jeśli nie uda się pobrać zaobserwowanego certyfikatu, będzie on kontynuowany w wierszu, a następnie hibernacji do następnego cyklu. Rozszerzenie maszyny wirtualnej usługi Service Fabric jako agent uruchamiania klastra wymaga zadeklarowanych certyfikatów, zanim klaster będzie mógł utworzyć. Oznacza to z kolei, że rozszerzenie maszyny wirtualnej usługi Service Fabric może działać dopiero po pomyślnym pobraniu certyfikatów klastra, oznaczonym tutaj klauzulą json "provisionAfterExtensions" : [ "KVVMExtension" ]" i ustawieniem rozszerzenia json "requireInitialSync": true maszyny wirtualnej usługi Key Vault.

Wskazuje to na rozszerzenie maszyny wirtualnej usługi Key Vault, które w pierwszym uruchomieniu (po wdrożeniu lub ponownym uruchomieniu) musi przechodzić przez obserwowane certyfikaty do momentu pomyślnego pobrania wszystkich. Ustawienie tego parametru na false w połączeniu z niepowodzeniem pobierania certyfikatów klastra spowoduje niepowodzenie wdrożenia klastra. Z drugiej strony wymaganie początkowej synchronizacji z nieprawidłową lub nieprawidłową listą obserwowanych certyfikatów spowodowałoby awarię rozszerzenia maszyny wirtualnej usługi Key Vault i, ponownie, niepowodzenie wdrożenia klastra.

Łączenie certyfikatów, objaśnienie

Być może zauważono flagę rozszerzenia linkOnRenewal maszyny wirtualnej usługi Key Vault i fakt, że jest ona ustawiona na wartość false. To ustawienie dotyczy zachowania kontrolowanego przez tę flagę i jego wpływu na funkcjonowanie klastra. To zachowanie jest specyficzne dla systemu Windows.

Zgodnie z definicją:

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

Certyfikaty używane do nawiązywania połączenia TLS są zwykle uzyskiwane jako dojście za pośrednictwem dostawcy pomocy technicznej zabezpieczeń S-channel. Oznacza to, że klient nie uzyskuje bezpośredniego dostępu do klucza prywatnego samego certyfikatu. Kanał S-channel obsługuje przekierowywanie lub łączenie poświadczeń w postaci rozszerzenia certyfikatu, CERT_RENEWAL_PROP_ID.

Jeśli ta właściwość jest ustawiona, jego wartość reprezentuje odcisk palca certyfikatu odnawiania , dlatego kanał S zamiast tego podejmie próbę załadowania połączonego certyfikatu. W rzeczywistości kanał S-channel przejdzie przez ten połączony i, miejmy nadzieję, listy acyklicznej, dopóki nie skończy się ostatecznym certyfikatem, jeden bez znaku odnowienia. Ta funkcja, gdy jest używana rozsądnie, jest doskonałym ograniczeniem ryzyka utraty dostępności spowodowanej na przykład wygasłymi certyfikatami.

W innych przypadkach może to być przyczyna awarii, które są trudne do zdiagnozowania i ograniczenia. S-channel wykonuje przechodzenie certyfikatów na ich właściwości odnowienia bezwarunkowo, niezależnie od podmiotu, wystawców lub innych określonych atrybutów, które uczestniczą w weryfikacji wynikowego certyfikatu przez klienta. Możliwe, że wynikowy certyfikat nie ma skojarzonego klucza prywatnego lub że klucz nie został przechowany do potencjalnego konsumenta.

Jeśli łączenie jest włączone, rozszerzenie maszyny wirtualnej usługi Key Vault po pobraniu zaobserwowanego certyfikatu z magazynu kluczy podejmie próbę znalezienia pasujących, istniejących certyfikatów w celu połączenia ich za pośrednictwem właściwości rozszerzenia odnawiania. Dopasowanie jest oparte wyłącznie na alternatywnej nazwie podmiotu (SAN) i działa, jeśli istnieją dwa istniejące certyfikaty, jak pokazano w następujących przykładach: A: Nazwa certyfikatu (CN) = "Akcesoria Alicji", SAN = {"alice.universalexports.com"}, odnowienie = '' B: CN = "Bity Boba", SAN = {"bob.universalexports.com", "bob.universalexports.net"}, odnowienie = ''

Załóżmy, że certyfikat C jest pobierany przez rozszerzenie maszyny wirtualnej usługi Key Vault: CN = "malware Mallory", SAN = {"alice.universalexports.com", "bob.universalexports.com", "mallory.universalexports.com"}

Lista SIECI SAN certyfikatu A jest w pełni zawarta w C, a więc A.renewal = C.thumbprint. Lista SAN certyfikatu B ma wspólne skrzyżowanie z C, ale nie jest w pełni zawarte w nim, więc odnawianie B.pozostaje puste.

Każda próba wywołania klasy AcquireCredentialsHandle (S-channel) w tym stanie na certyfikacie A kończy się wysłaniem języka C do strony zdalnej. W przypadku usługi Service Fabric podsystem transportowy klastra używa kanału S do wzajemnego uwierzytelniania, dlatego opisane wcześniej zachowanie wpływa bezpośrednio na podstawową komunikację klastra. Kontynuując poprzedni przykład i zakładając, że A jest certyfikatem klastra, to, co się dzieje dalej, zależy od:

• Jeśli klucz prywatny języka C nie jest acLed na koncie, w którym działa usługa Service Fabric, zobaczysz błędy uzyskiwania klucza prywatnego (SEC_E_UNKNOWN_CREDENTIALS lub podobne).
• Jeśli klucz prywatny języka C jest dostępny, zobaczysz błędy autoryzacji zwrócone przez inne węzły (CertificateNotMatched, brak autoryzacji itd.).

W obu przypadkach transport kończy się niepowodzeniem, a klaster może spaść. Objawy różnią się. Co gorsza, łączenie zależy od kolejności odnowienia, która jest dyktowana kolejnością listy obserwowanych certyfikatów rozszerzenia maszyny wirtualnej usługi Key Vault, harmonogramem odnawiania w magazynie kluczy, a nawet przejściowymi błędami, które mogłyby zmienić kolejność pobierania.

Aby zapobiec takim zdarzeniu, zalecamy wykonanie następujących czynności:

• Nie należy mieszać alternatywnych nazw podmiotów różnych certyfikatów magazynu. Każdy certyfikat magazynu powinien obsługiwać odrębny cel, a jego podmiot i sieć SAN powinny odzwierciedlać to z specyfiką.

• Uwzględnij nazwę pospolitą podmiotu na liście SIECI SAN (dosłownie CN=<subject common name>).

• Jeśli nie masz pewności, jak kontynuować, wyłącz łączenie przy odnawianiu certyfikatów aprowizowania przy użyciu rozszerzenia maszyny wirtualnej usługi Key Vault.

  Uwaga

  Wyłączenie łączenia jest właściwością najwyższego poziomu rozszerzenia maszyny wirtualnej usługi Key Vault i nie można jej ustawić dla poszczególnych obserwowanych certyfikatów.

Dlaczego należy używać tożsamości zarządzanej przypisanej przez użytkownika? Jakie są implikacje korzystania z niego?

Jak widać w poprzednich fragmentach kodu JSON, wymagane jest sekwencjonowanie operacji i aktualizacji w celu zagwarantowania powodzenia konwersji i utrzymania dostępności klastra. W szczególności zasób zestawu skalowania maszyn wirtualnych deklaruje i używa jego tożsamości do pobierania wpisów tajnych w pojedynczej aktualizacji (z perspektywy użytkownika).

Rozszerzenie maszyny wirtualnej usługi Service Fabric, które uruchamia klaster, zależy od ukończenia rozszerzenia maszyny wirtualnej usługi Key Vault, które z kolei zależy od pomyślnego pobrania obserwowanych certyfikatów.

Rozszerzenie maszyny wirtualnej usługi Key Vault używa tożsamości zestawu skalowania maszyn wirtualnych w celu uzyskania dostępu do magazynu kluczy, co oznacza, że zasady dostępu w magazynie kluczy muszą zostać już zaktualizowane przed wdrożeniem zestawu skalowania maszyn wirtualnych.

Aby usunąć tworzenie tożsamości zarządzanej lub przypisać ją do innego zasobu, operator wdrażania musi mieć wymaganą rolę (ManagedIdentityOperator) w subskrypcji lub grupie zasobów oprócz ról wymaganych do zarządzania innymi zasobami, do których odwołuje się szablon.

Z punktu widzenia zabezpieczeń należy pamiętać, że zestaw skalowania maszyn wirtualnych jest uważany za granicę zabezpieczeń w odniesieniu do tożsamości platformy Azure. Oznacza to, że każda aplikacja hostowana na maszynie wirtualnej może w zasadzie uzyskać token dostępu reprezentujący maszynę wirtualną. Tokeny dostępu tożsamości zarządzanej są uzyskiwane z nieuwierzytelnionego punktu końcowego usługi metadanych wystąpienia. Jeśli uważasz, że maszyna wirtualna ma być środowiskiem udostępnionym lub wielodostępnym, ta metoda pobierania certyfikatów klastra może nie być wskazana. Jest to jednak jedyny mechanizm aprowizacji odpowiedni do automatycznego wyrejestrowywania certyfikatów.

Rozwiązywanie problemów i często zadawane pytania

.: Jak programowo zarejestrować się w certyfikacie zarządzanym przez usługę Key Vault?

Znajdź nazwę wystawcy z dokumentacji usługi Key Vault, a następnie zastąp ją następującym skryptem:

  $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 

.: Co się stanie, gdy certyfikat zostanie wystawiony przez nieokreślonego wystawcę lub nieokreślonego? Gdzie mogę uzyskać wyczerpującą listę aktywnych wystawców konkretnej infrastruktury kluczy publicznych?

Jeśli deklaracja certyfikatu określa odciski palca wystawcy, a bezpośredni wystawca certyfikatu nie znajduje się na liście przypiętych wystawców, certyfikat zostanie uznany za nieprawidłowy, niezależnie od tego, czy jego katalog główny jest zaufany przez klienta. W związku z tym niezwykle ważne jest zapewnienie, że lista wystawców jest aktualna. Wprowadzenie nowego wystawcy jest rzadkim zdarzeniem i powinno być szeroko nagłośnione, zanim zacznie wystawiać certyfikaty.

Ogólnie rzecz biorąc, infrastruktura kluczy publicznych publikuje i utrzymuje oświadczenie dotyczące praktyki certyfikacji zgodnie z IETF RFC 7382. Oprócz innych informacji instrukcja zawiera wszystkich aktywnych wystawców. Pobieranie tej listy programowo może się różnić od jednej infrastruktury kluczy publicznych do innej.

W przypadku wewnętrznych kluczy publicznych firmy Microsoft zapoznaj się z wewnętrzną dokumentacją dotyczącą punktów końcowych i zestawów SDK używanych do pobierania autoryzowanych wystawców. Właściciel klastra jest odpowiedzialny za okresowe przeglądanie tej listy, aby upewnić się, że ich definicja klastra obejmuje wszystkich oczekiwanych wystawców.

.: Czy jest obsługiwanych wiele PKI?

Tak. Nie można zadeklarować wielu wpisów CN w manifeście klastra o tej samej wartości, ale można wyświetlić listę wystawców z wielu PKI, które odpowiadają tej samej pospolitej pospolitii. Nie jest to zalecana praktyka, a praktyki przejrzystości certyfikatów mogą uniemożliwić wystawianie takich certyfikatów. Jednak jako środek migracji z jednej infrastruktury kluczy publicznych do innej jest to akceptowalny mechanizm.

.: Co zrobić, jeśli bieżący certyfikat klastra nie jest wystawiony przez urząd certyfikacji lub nie ma zamierzonego tematu?

Uzyskaj certyfikat z zamierzonym tematem i dodaj go do definicji klastra jako pomocniczego odcisku palca. Po pomyślnym zakończeniu uaktualniania zainicjuj kolejne uaktualnienie konfiguracji klastra, aby przekonwertować deklarację certyfikatu na nazwę pospolitą.