Verwalten von Zertifikaten in Service Fabric-Clustern

  • Artikel

In diesem Artikel werden die Verwaltungsaspekte von Zertifikaten behandelt, die zur Sicherung der Kommunikation in Azure Service Fabric-Clustern verwendet werden. Er ergänzt die Einführung in Service Fabric-Clustersicherheit und die Erläuterung zur zertifikatbasierten X.509-Authentifizierung in Service Fabric.

Voraussetzungen

Bevor Sie beginnen, sollten Sie mit den grundlegenden Sicherheitskonzepten und den Kontrollmöglichkeiten vertraut sein, die Service Fabric zur Konfiguration der Sicherheit eines Clusters bietet.

Haftungsausschluss

Dieser Artikel verbindet theoretische Aspekte der Zertifikatverwaltung mit praktischen Beispielen, die sich mit den Besonderheiten von Diensten, Technologien usw. befassen. Da ein Großteil der Zielgruppe hier Microsoft-intern ist, bezieht sich der Artikel auf Dienste, Technologien und Produkte, die spezifisch für Azure sind. Wenn bestimmte Microsoft-spezifische Details nicht auf Sie zutreffen, können Sie im Kommentarbereich am Ende um eine Erläuterung oder Anleitung bitten.

Definieren der Zertifikatverwaltung

Wie Sie im begleitenden Artikel Zertifikatbasierte X.509-Authentifizierung in Service Fabric-Clustern erfahren, ist ein Zertifikat ein kryptografisches Objekt, das im Wesentlichen ein asymmetrisches Schlüsselpaar mit Attributen verbindet, die die Entität beschreiben, die es darstellt.

Ein Zertifikat ist jedoch auch ein vergängliches Objekt, da seine Lebensdauer endlich ist und es anfällig für Kompromittierung ist. Eine versehentliche Offenlegung oder ein erfolgreicher Exploit kann ein Zertifikat vom Sicherheitsstandpunkt aus unbrauchbar machen. Diese Eigenschaften implizieren die Notwendigkeit, Zertifikate entweder routinemäßig oder als Reaktion auf einen Sicherheitsvorfall zu ändern.

Ein weiterer Aspekt der Zertifikatverwaltung und ein völlig anderes Thema ist die Sicherung der privaten Schlüssel oder Geheimnisse von Zertifikaten, die die Identität der an der Beschaffung und Bereitstellung von Zertifikaten beteiligten Stellen schützen.

Wir beschreiben Zertifikatverwaltung als die Prozesse und Verfahren, die verwendet werden, um Zertifikate abzurufen und sie sicher und geschützt dorthin zu transportieren, wo sie benötigt werden.

Einige Verwaltungsvorgänge, z. B. Registrierung, Festlegung von Richtlinien und Autorisierungskontrollen, werden in diesem Artikel nicht behandelt. Andere Vorgänge, wie die Bereitstellung, Erneuerung, Neuverschlüsselung oder der Sperrung, stehen nur zufällig mit Service Fabric in Verbindung. Nichtsdestotrotz wird in diesem Artikel ein wenig darauf eingegangen, denn das Verständnis dieser Vorgänge kann Ihnen helfen, Ihren Cluster richtig abzusichern.

Ihr unmittelbares Ziel ist es wahrscheinlich, die Zertifikatverwaltung so weit wie möglich zu automatisieren, um die ununterbrochene Verfügbarkeit des Clusters zu gewährleisten. Da der Prozess ohne Benutzereingriff abläuft, möchten Sie auch Sicherheitszusicherungen bieten. Mit Service Fabric-Clustern ist dieses Ziel erreichbar.

Der Rest des Artikels befasst sich zunächst mit der Zertifikatverwaltung und dann mit der Aktivierung von automatischem Rollover.

Insbesondere werden die folgenden Themen behandelt:

  • Annahmen über die Trennung der Zuständigkeiten zwischen Besitzer und Plattform
  • Der lange Weg von der Ausstellung der Zertifikate bis zur Nutzung
  • Rotation von Zertifikaten: warum, wie und wann
  • Was kann möglicherweise schief gehen?

Der Artikel behandelt die folgenden Themen nicht:

  • Sichern und Verwalten von Domänennamen
  • Registrieren bei Zertifikaten
  • Einrichten von Autorisierungskontrollen zum Erzwingen der Zertifikatausstellung.

Um weitere Informationen zu diesen Themen zu erhalten, wenden Sie sich an die Registrierungsstelle Ihres bevorzugten PKI-Infrastrukturdiensts (Public Key-Infrastruktur). Wenn Sie ein Microsoft-interner Benutzer sind, können Sie sich an Azure Security wenden.

An der Zertifikatverwaltung beteiligte Rollen und Entitäten

Der Sicherheitsansatz in einem Service Fabric-Cluster ist ein Fall des Typs „Clustereigentümer deklariert Sicherheit, Service Fabric-Laufzeit erzwingt sie“. Das bedeutet, dass fast keine der Zertifikate, Schlüssel oder anderen Berechtigungsnachweise von Identitäten, die an der Funktion eines Clusters teilnehmen, vom Dienst selbst stammen. Sie werden alle vom Clusterbesitzer deklariert. Der Clusterbesitzer ist auch dafür verantwortlich, die Zertifikate im Cluster bereitzustellen, sie bei Bedarf zu erneuern und für ihre Sicherheit zu sorgen.

Genauer gesagt muss der Clusterbesitzer sicherstellen, dass:

  • Zertifikate, die im Abschnitt NodeType des Clustermanifests deklariert werden, können gemäß den Präsentationsregeln auf jedem Knoten dieses Typs gefunden werden.
  • Zertifikate, die wie im vorangegangenen Aufzählungspunkt deklariert werden, werden mit ihren entsprechenden privaten Schlüsseln installiert.
  • In den Präsentationsregeln deklarierte Zertifikate sollten die Validierungsregeln bestehen.

Service Fabric übernimmt seinerseits die folgenden Aufgaben:

  • Auffinden von Zertifikaten, die den Deklarationen in der Clusterdefinition entsprechen
  • Gewähren von Zugriff nach Bedarf auf die entsprechenden privaten Schlüssel für von Service Fabric kontrollierte Entitäten
  • Validieren von Zertifikaten in strikter Übereinstimmung mit bewährten Sicherheitsverfahren und der Clusterdefinition
  • Auslösen von Warnungen bei bevorstehendem Ablauf von Zertifikaten oder bei Nichtdurchführung der grundlegenden Schritte zur Validierung von Zertifikaten
  • Validieren (bis zu einem gewissen Grad), dass die zertifikatbezogenen Aspekte der Clusterdefinition von der zugrunde liegenden Konfiguration der Hosts erfüllt werden

Daraus folgt, dass die Last der Zertifikatverwaltung (als aktive Vorgänge) allein dem Clusterbesitzer zufällt. In den folgenden Abschnitten werden die einzelnen Verwaltungsvorgänge sowie die verfügbaren Mechanismen und ihre Auswirkungen auf den Cluster näher erläutert.

Der Weg eines Zertifikats

Lassen Sie uns kurz den Verlauf eines Zertifikats von der Ausstellung bis zur Nutzung im Kontext eines Service Fabric-Clusters skizzieren:

  1. Ein Domänenbesitzer registriert beim RA einer PKI eine Domäne oder einen Antragsteller, die bzw. den er mit den sich daraus ergebenden Zertifikaten verknüpfen möchte. Die Zertifikate wiederum sind der Nachweis für den Besitz der Domäne oder des Antragstellers.

  2. Der Domänenbesitzer benennt im RA auch die Identitäten der autorisierten anfordernden Personen, d. h. der Entitäten, die berechtigt sind, die Registrierung von Zertifikaten für die angegebene Domäne oder den angegebenen Antragsteller zu beantragen.

  3. Eine autorisierte anfordernde Person registriert sich dann über einen Dienst zum Verwalten von Geheimnissen bei einem Zertifikat. In Azure ist der bevorzugte Dienst zur Verwaltung von Geheimnissen Azure Key Vault. Dort werden Geheimnisse und Zertifikate sicher gespeichert, und der Abruf durch autorisierte Entitäten wird ermöglicht. Key Vault dient auch zum Verlängern bzw. Neuvergeben des Zertifikats gemäß der Konfiguration in der zugehörigen Zertifikatrichtlinie. Key Vault verwendet Microsoft Entra ID als Identitätsanbieter.

  4. Ein autorisierter Abrufer oder Bereitstellungs-Agent ruft das Zertifikat einschließlich seines privaten Schlüssels aus dem Schlüsseltresor ab und installiert es auf den Computern, die den Cluster hosten.

  5. Der Service Fabric-Dienst (der auf jedem Knoten mit erhöhten Rechten ausgeführt wird) gewährt berechtigten Service Fabric-Entitäten Zugriff auf das Zertifikat. Diese werden von lokalen Gruppen bestimmt und in ServiceFabricAdministrators (Service Fabric-Administratoren) und ServiceFabricAllowedUsers (zulässige Service Fabric-Benutzer) aufgeteilt.

  6. Die Service Fabric-Runtime greift auf das Zertifikat zu und nutzt es, um einen Verbund einzurichten oder um sich bei eingehenden Anforderungen von autorisierten Clients zu authentifizieren.

  7. Der Bereitstellungs-Agent überwacht das Schlüsseltresorzertifikat und löst beim Erkennen der Verlängerung den Bereitstellungsflow aus. Der Clusterbesitzer aktualisiert dann ggf. die Clusterdefinition, um die Absicht anzuzeigen, das Zertifikat zu übertragen.

  8. Der Bereitstellungs-Agent oder Clusterbesitzer ist auch für die Bereinigung und Löschung nicht verwendeter Zertifikate verantwortlich.

Für die Zwecke dieses Artikels sind die ersten beiden Schritte der vorangegangenen Abfolge weitgehend unabhängig voneinander. Ihre einzige Verbindung besteht darin, dass der allgemeine Name des Antragstellers des Zertifikats der DNS-Name ist, der in der Clusterdefinition deklariert wird.

Der Ablauf der Zertifikatausstellung und -bereitstellung wird in den folgenden Abbildungen dargestellt:

Für Zertifikate, die durch Fingerabdruck deklariert werden

Diagram of provisioning certificates that are declared by thumbprint.

Für Zertifikate, die durch den allgemeinen Namen des Antragstellers deklariert werden

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

Zertifikatregistrierung

Das Thema der Zertifikatregistrierung wird ausführlich in der Key Vault-Dokumentation behandelt. Aus Gründen der Kontinuität und zum leichteren Nachschlagen ist hier eine Zusammenfassung enthalten.

Um mit Azure als Kontext fortzufahren und Key Vault als Dienst zur Verwaltung von Geheimnissen zu nutzen, muss eine autorisierte, ein Zertifikat anfordernde Person mindestens die vom Schlüsseltresorbesitzer erteilten Berechtigungen zur Zertifikatverwaltung für den Schlüsseltresor haben. Die anfordernde Person registriert sich dann wie folgt bei einem Zertifikat:

  • Die anfordernde Person erstellt eine Zertifikatrichtlinie in Azure Key Vault, die die Domäne bzw. den Antragsteller des Zertifikats, den gewünschten Aussteller, den Schlüsseltyp und die -länge, die beabsichtigte Schlüsselverwendung und mehr angibt. Weitere Informationen finden Sie unter Zertifikate in Azure Key Vault.

  • Die anfordernde Person erstellt ein Zertifikat im selben Tresor mit der Richtlinie, die im vorherigen Schritt angegeben wurde. Dies wiederum generiert ein Schlüsselpaar als Tresorobjekte und eine Zertifikatsignaturanforderung, die mit dem privaten Schlüssel signiert wird und dann zum Signieren an den benannten Aussteller weitergeleitet wird.

  • Nachdem der Aussteller oder die Zertifizierungsstelle (ZS) mit dem signierten Zertifikat geantwortet hat, wird das Ergebnis im Schlüsseltresor zusammengeführt, woraufhin die Zertifikatdaten wie folgt zur Verfügung stehen:

    • Unter {vaultUri}/certificates/{name}: Das Zertifikat einschließlich des öffentlichen Schlüssels und der Metadaten.
    • Unter {vaultUri}/keys/{name}: Der für kryptografische Vorgänge verfügbare private Schlüssel des Zertifikats (umbrechen/Umbruch aufheben, signieren/überprüfen).
    • Unter {vaultUri}/secrets/{name}: Das Zertifikat einschließlich des privaten Schlüssels, herunterladbar als ungeschützte PFX- oder PEM-Datei.

Erinnern Sie sich daran, dass ein Zertifikat im Schlüsseltresor eine chronologische Liste von Zertifikatinstanzen enthält, die eine Richtlinie gemeinsam verwenden. Zertifikatversionen werden entsprechend der Attribute für Gültigkeitsdauer und Verlängerung dieser Richtlinie erstellt. Es wird ausdrücklich empfohlen, dass Tresorzertifikate keine Antragsteller oder Domänen bzw. DNS-Namen gemeinsam verwenden. Es kann in einem Cluster problematisch sein, Zertifikatinstanzen aus verschiedenen Tresorzertifikaten mit identischen Antragstellern, aber deutlich unterschiedlichen anderen Attributen wie Aussteller, Schlüsselverwendungen usw. bereitzustellen. Zu diesem Zeitpunkt ist ein Zertifikat im Schlüsseltresor vorhanden und kann verwendet werden. Sehen wir uns nun den Rest des Prozesses an.

Zertifikatbereitstellung

Wir haben einen „Bereitstellungs-Agent erwähnt, bei dem es sich um die Entität handelt, die das Zertifikat einschließlich seines privaten Schlüssels aus dem Schlüsseltresor abruft und auf jedem der Hosts des Clusters installiert. (Denken Sie daran, dass Service Fabric keine Zertifikate bereitstellt.)

Im Kontext dieses Artikels wird der Cluster in einer Sammlung von Azure-VMs oder VM-Skalierungsgruppen gehostet. In Azure können Sie mithilfe der folgenden Mechanismen ein Zertifikat aus einem Tresor auf einer VM bzw. in einer VM-Skalierungsgruppe bereitstellen. Dies setzt wie schon zuvor voraus, dass dem Bereitstellungs-Agent zuvor vom Besitzer des Schlüsseltresors geheime get-Berechtigungen für den Schlüsseltresor gewährt wurden.

  • Ad-hoc: Ein Bediener ruft das Zertifikat aus dem Schlüsseltresor (im Format PFX/PKCS #12 oder PEM) ab und installiert es auf jedem Knoten.

    Der Ad-hoc-Mechanismus wird aus mehreren Gründen, die von der Sicherheit bis zur Verfügbarkeit reichen, nicht empfohlen und soll hier nicht weiter erörtert werden. Weitere Informationen finden Sie unter FAQ zu Azure-VM-Skalierungsgruppen.

  • Als Geheimnis einer VM-Skalierungsgruppe während der Bereitstellung: Der Computedienst ruft unter Verwendung seiner Erstanbieteridentität im Namen des Bedieners das Zertifikat aus einem für die Vorlagenbereitstellung aktivierten Tresor ab und installiert es auf jedem Knoten der VM-Skalierungsgruppe, wie in den FAQ zu Azure-VM-Skalierungsgruppen beschrieben.

    Hinweis

    Dieser Ansatz ermöglicht nur die Bereitstellung von Geheimnissen mit Versionsangaben.

  • Durch Verwenden der Key Vault-VM-Erweiterung. Auf diese Weise können Sie Zertifikate mithilfe von versionslosen Deklarationen mit regelmäßiger Aktualisierung von beobachteten Zertifikaten bereitstellen. In diesem Fall wird erwartet, dass die VM bzw.die VM-Skalierungsgruppe über eine verwaltete Identität verfügt, d. h. eine Identität, der Zugriff auf die Schlüsseltresore mit den überwachten Zertifikaten gewährt wurde.

Die VMSS-/computebasierte Bereitstellung bietet Vorteile in Bezug auf Sicherheit und Verfügbarkeit, bringt aber auch Einschränkungen mit sich. Sie erfordert von vornherein, dass Sie Zertifikate als Geheimnisse mit Versionsangabe deklarieren. Dadurch ist die VMSS-/computebasierte Bereitstellung nur für Cluster geeignet, die mit Zertifikaten gesichert sind, die durch einen Fingerabdruck deklariert wurden.

Im Gegensatz dazu wird bei der auf der Key Vault-VM-Erweiterung basierenden Bereitstellung immer die neueste Version jedes überwachten Zertifikats installiert. Dadurch eignet sie sich nur für Cluster, die mit Zertifikaten abgesichert sind, die mit dem allgemeinen Namen des Antragstellers deklariert wurden. Zur Hervorhebung: Verwenden Sie keinen Bereitstellungsmechanismus mit automatischer Aktualisierung (wie z. B. die Key Vault-VM-Erweiterung) für Zertifikate, die nach Instanz (d. h. über einen Fingerabdruck) deklariert wurden. Das Risiko des Verlusts der Verfügbarkeit ist beträchtlich.

Andere Bereitstellungsmechanismen sind vorhanden, aber die hier genannten Ansätze sind die derzeit akzeptierten Optionen für Azure Service Fabric-Cluster.

Nutzung und Überwachung von Zertifikaten

Wie bereits erwähnt, ist die Service Fabric-Laufzeit für das Auffinden und Nutzen der in der Clusterdefinition deklarierten Zertifikate verantwortlich. Im Artikel zur zertifikatbasierten X.509-Authentifizierung in Service Fabric-Clustern wird ausführlich erläutert, wie Service Fabric die Präsentations- und Validierungsregeln implementiert. Dieses Thema wird hier nicht erneut aufgegriffen. Dieser Artikel befasst sich mit Zugriff und Berechtigungserteilung sowie mit Überwachung.

Rufen Sie sich in Erinnerung, dass Zertifikate in Service Fabric für eine Vielzahl von Zwecken verwendet werden – von der gegenseitigen Authentifizierung auf Verbundebene bis zur TLS-Authentifizierung (Transport Layer Security) der Verwaltungsendpunkte. Dies erfordert, dass verschiedene Komponenten oder Systemdienste Zugriff auf den privaten Schlüssel des Zertifikats besitzen. Die Service Fabric-Runtime durchsucht den Zertifikatspeicher regelmäßig nach Übereinstimmungen mit jeder der bekannten Präsentationsregeln.

Für jedes übereinstimmende Zertifikat wird der entsprechende private Schlüssel ermittelt, und seine diskrete Zugriffssteuerungsliste wird aktualisiert, um Berechtigungen (normalerweise „Lesen“ und „Ausführen“) einzuschließen, die der Identität gewährt werden, die sie benötigt.

Dieser Prozess wird informell als ACLing [Hinzufügen zur ACL] bezeichnet. Der Prozess läuft mit einer Taktfrequenz von einer Minute und betrifft auch Zertifikate für Anwendungen, z. B. solche, die zur Verschlüsselung von Einstellungen oder als Endpunktzertifikate zum Einsatz kommen. „ACLing“ richtet sich nach den Präsentationsregeln. Daher ist es wichtig zu bedenken, dass auf über einen Fingerabdruck deklarierte Zertifikate, die ohne die anschließende Aktualisierung der Clusterkonfiguration automatisch aktualisiert werden, nicht zugegriffen werden kann.

Rotation für Zertifikate

Hinweis

RFC 3647 von Internet Engineering Task Force (IETF) definiert Verlängerung formell als die Ausstellung eines Zertifikats mit denselben Attributen wie das Zertifikat, das ersetzt wird. Der Aussteller, der öffentliche Schlüssel des Antragstellers und die Informationen bleiben erhalten. Erneute Schlüsselerstellung ist die Ausstellung eines Zertifikats mit einem neuen Schlüsselpaar, ohne Einschränkungen, ob sich der Aussteller ändern kann. Da die Unterscheidung wichtig sein kann (denken Sie an Zertifikate, die per allgemeinem Namen des Antragstellers mit Anheftung an den Aussteller deklariert werden), wird in diesem Artikel der neutrale Begriff Rotation verwendet, um beide Szenarien abzudecken. Denken Sie daran, dass der Begriff Verlängerung sich auf Neuverschlüsselung bezieht, wenn er informell verwendet wird.

Wie bereits erwähnt, unterstützt Key Vault automatische Zertifikatrotation. Dies bedeutet, dass die zugehörige Zertifikatrichtlinie den Zeitpunkt festlegt, an dem das Zertifikat im Tresor rotiert wird, entweder anhand von Tagen vor Ablauf oder als Prozentsatz der Gesamtgültigkeitsdauer. Der Bereitstellungs-Agent muss nach diesem Zeitpunkt und vor dem Ablauf des nun vorherigen Zertifikats aufgerufen werden, um dieses neue Zertifikat an alle Knoten im Cluster zu verteilen.

Service Fabric unterstützt diesen Vorgang, indem Integritätswarnungen ausgelöst werden, wenn das Ablaufdatum eines Zertifikats (das derzeit im Cluster verwendet wird) vor einem vorgegebenen Intervall eintritt. Ein automatischer Bereitstellungs-Agent, die Key Vault-VM-Erweiterung, der so konfiguriert ist, dass er das Zertifikat des Schlüsseltresors überwacht, fragt den Schlüsseltresor regelmäßig ab, erkennt die Rotation, ruft das neue Zertifikat ab und installiert es. Die Bereitstellung über die Funktion secrets der VM/VMSS erfordert, dass ein autorisierter Operator die VM/VMSS mit dem Key Vault-URI mit Versionsangabe aktualisiert, der dem neuen Zertifikat entspricht.

Das rotierte Zertifikat wird jetzt für alle Knoten bereitgestellt. Unter der Annahme, dass die auf das Clusterzertifikat angewendete Rotation durch den allgemeinen Namen des Antragstellers deklariert wurde, wollen wir nun untersuchen, was im nächsten Schritt geschieht:

  • Bei neuen Verbindungen innerhalb des Clusters sowie mit dem Cluster findet und wählt die Service Fabric-Laufzeit das passende Zertifikat, das zuletzt ausgestellt wurde (größter Wert der Eigenschaft NotBefore). Dies ist eine Änderung gegenüber früheren Versionen der Service Fabric-Runtime.

  • Bestehende Verbindungen bleiben aktiv bzw. können natürlich ablaufen oder anderweitig beendet werden, und ein interner Handler wurde benachrichtigt, dass es eine neue Übereinstimmung gibt.

Hinweis

Derzeit (ab Version 7.2 CU4 oder höher) wählt Service Fabric das Zertifikat mit dem größten (zuletzt ausgestellten) NotBefore-Eigenschaftswert aus. Vor Version 7.2 CU4 hat Service Fabric das gültige Zertifikat mit dem größten (zuletzt ablaufenden) NotAfter-Wert ausgewählt.

Daraus ergeben sich die folgenden wichtigen Beobachtungen:

  • Die Verfügbarkeit des Clusters oder der gehosteten Anwendungen genießt Vorrang vor der Anweisung, das Zertifikat zu rotieren. Der Cluster wird schließlich auf das neue Zertifikat umgestellt, allerdings ohne Zeitgarantie. Daraus folgt:

    • Für den Betrachter mag es nicht sofort ersichtlich sein, dass das rotierte Zertifikat seinen Vorgänger vollständig ersetzt. Die einzige Möglichkeit, die sofortige Ersetzung des derzeit verwendeten Zertifikats zu erzwingen, besteht darin, die Hostcomputer neu zu starten. Es reicht nicht aus, die Service Fabric-Knoten neu zu starten, da die Kernelmoduskomponenten, die Leaseverbindungen in einem Cluster herstellen, hiervon nicht betroffen sind. Ein Neustart der VM/VMSS kann zu einem vorübergehenden Verlust von Verfügbarkeit führen. Bei Anwendungszertifikaten genügt es, nur die jeweiligen Anwendungsinstanzen neu zu starten.

    • Die Einführung eines neu vergebenen Zertifikats, das die Validierungsregeln nicht erfüllt, kann den Cluster praktisch außer Betrieb setzen. Das häufigste Beispiel hierfür ist der Fall eines unerwarteten Ausstellers. Die Clusterzertifikate werden über den allgemeinen Namen des Antragstellers mit Anheftung an den Aussteller deklariert, aber das rotierte Zertifikat wurde von einem neuen bzw. nicht deklarierten Aussteller ausgestellt.

Zertifikatbereinigung

Gegenwärtig gibt es in Azure keine Vorkehrungen für das explizite Entfernen von Zertifikaten. Es ist oft eine nicht triviale Aufgabe festzustellen, ob ein bestimmtes Zertifikat zu einem bestimmten Zeitpunkt verwendet wird. Dies ist bei Anwendungszertifikaten schwieriger als bei Clusterzertifikaten. Da Service Fabric selbst nicht der Bereitstellungs-Agent ist, wird ein vom Benutzer deklariertes Zertifikat unter keinen Umständen gelöscht. Für die Standardbereitstellungsmechanismen gilt Folgendes:

  • Zertifikate, die als VM/VMSS-Geheimnisse deklariert sind, werden bereitgestellt, solange sie in der VM/VMSS-Definition referenziert werden und aus dem Schlüsseltresor abrufbar sind. Durch das Löschen eines Schlüsseltresorgeheimnisses oder Zertifikats schlagen nachfolgende VM/VMSS-Bereitstellungen fehl. Ebenso schlagen durch das Deaktivieren einer Geheimnisversion im Schlüsseltresor VM/VMSS-Bereitstellungen fehl, die auf die Geheimnisversion verweisen.

  • Frühere Versionen von Zertifikaten, die über die Key Vault VM-Erweiterung bereitgestellt werden, sind möglicherweise auf einem VM/VMSS-Knoten vorhanden – oder auch nicht. Der Agent ruft nur die aktuelle Version ab und installiert sie, entfernt aber keine Zertifikate. Beim Reimaging eines Knotens (das in der Regel monatlich erfolgt) wird der Zertifikatspeicher auf den Inhalt des Betriebssystemimages zurückgesetzt, sodass frühere Versionen implizit entfernt werden. Berücksichtigen Sie jedoch, dass das Aufskalieren einer VM-Skalierungsgruppe dazu führt, dass nur die aktuelle Version der überwachten Zertifikate installiert wird. Gehen Sie nicht von Homogenität der Knoten in Bezug auf die installierten Zertifikate aus.

Vereinfachen der Verwaltung: Beispiel für automatisches Rollover

Bisher wurden in diesem Artikel Mechanismen und Beschränkungen beschrieben, komplizierte Regeln und Definitionen dargelegt und düstere Prognosen über Ausfälle getroffen. Nun ist es an der Zeit zu zeigen, wie automatische Zertifikatverwaltung eingerichtet werden kann, um all diese Bedenken auszuräumen. Dies erfolgt im Kontext eines Azure Service Fabric-Clusters, der in einer PaaS-v2-VM-Skalierungsgruppe (Platform-as-a-Service) ausgeführt wird, und zwar wie folgt unter Verwendung von Azure Key Vault für die Verwaltung von Geheimnissen und das Nutzen von verwalteten Identitäten:

  • Die Validierung von Zertifikaten wird von Fingerabdruckanheftung in Anheftung von Antragsteller und Aussteller geändert. Jedes Zertifikat mit einem bestimmten Antragsteller eines bestimmten Ausstellers ist gleichermaßen vertrauenswürdig.
  • Zertifikate werden im einem vertrauenswürdigen Speicher (Key Vault) registriert, daraus abgerufen und von einem Agent (in diesem Fall von der Key Vault-VM-Erweiterung) aktualisiert.
  • Die Bereitstellung von Zertifikaten wird von basierend auf Bereitstellungszeit und Version (wie durch den Azure Compute-Ressourcenanbieter praktiziert) auf nach der Bereitstellung und unter Verwendung von versionslosen Key Vault-URIs umgestellt.
  • Der Zugriff auf den Schlüsseltresor wird über vom Benutzer zugewiesene verwaltete Identitäten gewährt, die während der Bereitstellung erstellt und der VM-Skalierungsgruppe zugewiesen werden.
  • Nach der Bereitstellung fragt der Agent (die Key Vault-VM-Erweiterung) die beobachteten Zertifikate auf jedem Knoten der VM-Skalierungsgruppe ab und aktualisiert sie. Die Zertifikatrotation ist somit vollständig automatisiert, da Service Fabric automatisch das aktuellste gültige Zertifikat auswählt.

Die Sequenz ist vollständig skriptfähig und automatisierbar und ermöglicht eine anfängliche Bereitstellung eines Clusters ohne Benutzereingriff, der für automatisches Rollover von Zertifikaten konfiguriert ist. In den nächsten Abschnitten finden Sie detaillierte Schritte, die eine Mischung aus PowerShell-Cmdlets und Fragmenten von JSON-Vorlagen enthalten. Die gleiche Funktionalität ist mit allen unterstützten Mitteln zur Interaktion mit Azure zu erreichen.

Hinweis

In diesem Beispiel wird davon ausgegangen, dass im Schlüsseltresor bereits ein Zertifikat vorhanden ist. Das Registrieren und Verlängern eines verwalteten Key Vault-Zertifikats erfordert als Voraussetzung manuelle Schritte, wie weiter oben in diesem Artikel beschrieben. Verwenden Sie für Produktionsumgebungen von Key Vault verwaltete Zertifikate. Wir haben ein Beispielskript eingefügt, das für eine Microsoft-interne PKI spezifisch ist.

Hinweis

Automatisches Zertifikatrollover ist nur für von einer Zertifizierungsstelle ausgestellte Zertifikate sinnvoll. Die Verwendung von selbstsignierten Zertifikaten, einschließlich derjenigen, die während der Bereitstellung eines Service Fabric-Clusters im Azure-Portal generiert wurden, ist unsinnig, aber für lokale oder von Entwicklern gehostete Bereitstellungen trotzdem möglich, wenn Sie den Ausstellerfingerabdruck mit dem des Blattzertifikats als übereinstimmend deklarieren.

Startpunkt

Der Kürze halber gehen wir von folgendem Ausgangszustand aus:

  • Der Service Fabric-Cluster ist vorhanden und wird mit einem von einer Zertifizierungsstelle ausgestellten und per Fingerabdruck deklarierten Zertifikat abgesichert.
  • Das Zertifikat ist in einem Schlüsseltresor gespeichert und wird als VM-Skalierungsgruppengeheimnis bereitgestellt.
  • Dasselbe Zertifikat wird verwendet, um den Cluster in Zertifikatdeklarationen zu konvertieren, die auf dem allgemeinen Namen basieren, damit er anhand von Antragsteller und Aussteller überprüft werden kann. Ist dies nicht der Fall, rufen Sie das von der Zertifizierungsstelle ausgestellte Zertifikat ab, das für diesen Zweck vorgesehen ist, und fügen Sie es der Clusterdefinition über den Fingerabdruck hinzu. Dieser Vorgang wird unter Hinzufügen oder Entfernen von Zertifikaten für einen Service Fabric-Cluster in Azure erläutert.

Hier ist ein JSON-Auszug aus einer Vorlage, die einem solchen Zustand entspricht. Der Auszug lässt viele erforderliche Einstellungen aus und veranschaulicht nur die zertifikatbezogenen Aspekte.

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

Im Wesentlichen besagt der Code oben, dass das Zertifikat mit Fingerabdruck json [parameters('primaryClusterCertificateTP')] , das unter dem Key Vault-URI json [parameters('clusterCertificateUrlValue')] gefunden wird, über den Fingerabdruck als das einzige Zertifikat des Clusters deklariert wird.

Als Nächstes richten wir die zusätzlichen Ressourcen ein, die erforderlich sind, um das automatische Rollover des Zertifikats sicherzustellen.

Einrichten der erforderlichen Ressourcen

Wie bereits erwähnt, wird ein Zertifikat, das als Geheimnis einer VM-Skalierungsgruppe bereitgestellt wird, vom Microsoft.Compute-Ressourcenanbieterdienst aus dem Schlüsseltresor abgerufen. Dies geschieht durch die Verwendung ihrer Erstanbieteridentität im Namen des Bereitstellungsoperators. Dieser Prozess ändert sich für das automatische Rollover. Sie wechseln zu einer verwalteten Identität, die der VM-Skalierungsgruppe zugewiesen ist und der GET-Berechtigungen für die Geheimnisse in diesem Tresor erteilt wurden.

Sie sollten die nächsten Auszüge zur gleichen Zeit bereitstellen. Sie werden einzeln nur für Play-by-Play-Analysen und Erläuterungen aufgeführt.

Definieren Sie zunächst eine vom Benutzer zugewiesene Identität (Standardwerte sind als Beispiele angegeben). Weitere Informationen finden Sie in der offiziellen Dokumentation.

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

Gewähren Sie dieser Identität nun Zugriff auf die Schlüsseltresorgeheimnisse. Die aktuellsten Informationen dazu finden Sie in der offiziellen Dokumentation.

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

Im nächsten Schritt führen Sie die folgenden Aufgaben aus:

  • Zuweisen der vom Benutzer zugewiesenen Identität zur VM-Skalierungsgruppe.
  • Deklarieren der Abhängigkeit der VM-Skalierungsgruppe von der Erstellung der verwalteten Identität und vom Ergebnis des Gewährens des Zugriffs auf den Schlüsseltresor.
  • Deklarieren der Key Vault-VM-Erweiterung und Erfordern des Abrufs der beobachteten Zertifikate beim Start. Weitere Informationen finden Sie in der offiziellen Dokumentation zur Key Vault-VM-Erweiterung für Windows.
  • Aktualisieren Sie die Definition der Service Fabric-VM-Erweiterung so, dass sie von der Key Vault-VM-Erweiterung abhängt, und konvertieren Sie die Clusterzertifikatdeklaration von „Fingerabdruck“ in „Allgemeiner Name“.

Hinweis

Diese Änderungen werden in einem einzigen Schritt vorgenommen, da sie in den Bereich derselben Ressource fallen.

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

Obwohl dies nicht explizit im Code oben aufgeführt wird, ist zu beachten, dass die URL des Schlüsseltresorzertifikats aus dem Abschnitt OsProfile der VM-Skalierungsgruppe entfernt wurde.

Der letzte Schritt ist die Aktualisierung der Clusterdefinition dergestalt, dass die Zertifikatdeklaration von Fingerabdruck in allgemeinen Namen geändert wird. Hier heften wir auch die Fingerabdrücke des Ausstellers an:

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

An diesem Punkt können Sie die oben genannten Aktualisierungen im Rahmen einer einzigen Bereitstellung ausführen. Der Ressourcenanbieterdienst für Service Fabric teilt seinerseits die Clusteraktualisierung in mehrere Schritte auf, wie im Abschnitt zum Konvertieren von Clusterzertifikaten von Fingerabdruck in allgemeinen Namen beschrieben.

Analyse und Beobachtungen

In diesem Abschnitt werden Konzepte und Prozesse erläutert, die im gesamten Artikel vorgestellt wurden, und es wird auf einige andere wichtige Aspekte hingewiesen.

Informationen zur Zertifikatbereitstellung

Die Key Vault-VM-Erweiterung wird als Bereitstellungs-Agent mit einer vorgegebenen Frequenz kontinuierlich ausgeführt. Falls ein überwachtes Zertifikat nicht abgerufen wird, wird mit dem nächsten in der Reihe fortgefahren. Dann folgt ein Wechsel in den Ruhezustand bis zum nächsten Zyklus. Die Service Fabric-VM-Erweiterung benötigt als Bootstrap-Agent des Clusters die deklarierten Zertifikate, bevor der Cluster gebildet werden kann. Dies wiederum bedeutet, dass die Service Fabric-VM-Erweiterung erst nach dem erfolgreichen Abruf der Clusterzertifikate, hier durch die json "provisionAfterExtensions" : [ "KVVMExtension" ]"-Klausel und die Einstellung json "requireInitialSync": true der Key Vault-VM-Erweiterung bezeichnet, ausgeführt werden kann.

Dies informiert die Key Vault-VM-Erweiterung, dass sie bei der ersten Ausführung (nach Bereitstellung oder Neustart) ihre überwachten Zertifikate durchlaufen muss, bis alle erfolgreich heruntergeladen wurden. Wenn dieser Parameter auf FALSE festgelegt wird und die Clusterzertifikate nicht abgerufen werden können, schlägt die Clusterbereitstellung fehl. Umgekehrt würde die Anforderung einer anfänglichen Synchronisierung mit einer falschen oder ungültigen Liste überwachter Zertifikate zu einem Fehler bei der Key Vault-VM-Erweiterung und damit wiederum zu einem Fehler bei der Bereitstellung des Clusters führen.

Erläuterung der Zertifikatverknüpfung

Möglicherweise ist Ihnen das linkOnRenewal-Flag der Key Vault-VM-Erweiterung und die Tatsache aufgefallen, dass es auf FALSE festgelegt ist. Diese Einstellung befasst sich mit dem von diesem Flag gesteuerten Verhalten und seinen Auswirkungen auf das Funktionieren eines Clusters. Dieses Verhalten ist für Windows spezifisch.

Laut zugehöriger Definition gilt Folgendes:

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

Zertifikate, die zum Herstellen einer TLS-Verbindung verwendet werden, werden in der Regel als Handle über den S-Channel Security Support Provider abgerufen. Das heißt, der Client greift nicht direkt auf den privaten Schlüssel des Zertifikats selbst zu. S-Channel unterstützt die Umleitung oder Verknüpfung von Anmeldeinformationen in Form einer Zertifikaterweiterung CERT_RENEWAL_PROP_ID.

Wenn diese Eigenschaft festgelegt ist, stellt ihr Wert den Fingerabdruck des Verlängerungszertifikats dar, sodass S-Channel stattdessen versucht, das verknüpfte Zertifikat zu laden. Tatsächlich durchläuft S-Channel diese verknüpfte (und hoffentlich azyklische) Liste, bis am Ende das letzte Zertifikat erreicht wird, das keine Verlängerungsmarkierung aufweist. Diese Funktion ist, wenn sie vernünftig eingesetzt wird, eine hervorragende Abhilfe gegen Verfügbarkeitsverluste, die z. B. durch abgelaufene Zertifikate verursacht werden.

In anderen Fällen kann sie die Ursache für Ausfälle sein, die schwer zu diagnostizieren und abzustellen sind. S-Channel führt das Durchlaufen von Zertifikaten bezüglich ihrer Verlängerungseigenschaften bedingungslos aus, und zwar unabhängig von Antragsteller, Aussteller oder anderen spezifischen Attributen, die an der Validierung des sich ergebenden Zertifikats durch den Client beteiligt sind. Es ist in der Tat möglich, dass das sich ergebende Zertifikat keinen zugehörigen privaten Schlüssel besitzt oder dass der Schlüssel nicht der ACL seines potenziellen Consumers hinzugefügt wurde.

Wenn Verknüpfung aktiviert ist, versucht die Key Vault-VM-Erweiterung beim Abrufen eines überwachten Zertifikats aus dem Schlüsseltresor, übereinstimmende, vorhandene Zertifikate zu finden, um sie über die Verlängerungserweiterungseigenschaft zu verknüpfen. Der Abgleich basiert ausschließlich auf dem Subject Alternative Name (SAN) und funktioniert, wenn zwei Zertifikate vorhanden sind, wie in den folgenden Beispielen gezeigt: A: Certificate name (CN) = "Alice‘s accessories", SAN = {"alice.universalexports.com"}, renewal = '' B: CN = "Bob‘s bits", SAN = {"bob.universalexports.com", "bob.universalexports.net"}, renewal = ''

Angenommen, ein Zertifikat C wird von der Key Vault-VM-Erweiterung abgerufen: "Mallory‘s Malware", SAN = {"alice.universalexports.com", "bob.universalexports.com", "mallory.universalexports.com"}

Die SAN-Liste von Zertifikat A ist vollständig in Zertifikat C enthalten, daher ist A.renewal = C.thumbprint. Die SAN-Liste von Zertifikat B hat eine gemeinsame Schnittmenge mit Zertifikat C, ist aber nicht vollständig in ihr enthalten, weshalb B.renewal leer bleibt.

Jeder Versuch, AcquireCredentialsHandle (S-Channel) in diesem Zustand für Zertifikat A aufzurufen, führt letztlich dazu, dass Zertifikat C an die Remotepartei gesendet wird. Bei Service Fabric verwendet das Transportsubsystem eines Clusters S-Channel zur gegenseitigen Authentifizierung. Daher wirkt sich das zuvor beschriebene Verhalten direkt auf die grundlegende Kommunikation des Clusters aus. Wenn wir das Beispiel oben fortsetzen und annehmen, dass Zertifikat A das Clusterzertifikat ist, hängt der weitere Verlauf von Folgendem ab:

  • Wenn der private Schlüssel von Zertifikat C nicht der ACL des Kontos hinzugefügt wurde, mit dem Service Fabric ausgeführt wird, kommt es zu Fehlern beim Abrufen des privaten Schlüssels (SEC_E_UNKNOWN_CREDENTIALS oder ähnlich).
  • Wenn auf den privaten Schlüssel von Zertifikat C zugegriffen werden kann, kommt es zu Autorisierungsfehlern, die von den anderen Knoten zurückgegeben werden (CertificateNotMatched, nicht autorisiert usw.).

In beiden Fällen schlägt der Transport fehl, und der Cluster kann ausfallen. Die Symptome sind unterschiedlich. Erschwerend kommt hinzu, dass die Verknüpfung von der Reihenfolge der Verlängerung abhängt. Diese wird durch die Reihenfolge in der Liste der überwachten Zertifikate der Key Vault-VM-Erweiterung, den Verlängerungszeitplan im Schlüsseltresor oder sogar durch vorübergehende Fehler vorgegeben, die die Reihenfolge des Abrufs verändern würden.

Um derartige Vorfälle zu vermeiden, wird Folgendes empfohlen:

  • Vermischen Sie nicht die alternativen Antragstellernamen verschiedener Tresorzertifikate. Jedes Tresorzertifikat sollte einen bestimmten Zweck erfüllen, und sein Antragsteller und SAN sollten diesen spezifischen Zweck widerspiegeln.

  • Fügen Sie den allgemeinen Namen des Antragstellers der SAN-Liste hinzu (wörtlich als „CN=<subject common name>“).

  • Wenn Sie sich nicht sicher sind, wie Sie fortfahren sollten, deaktivieren Sie Verknüpfung für die Verlängerung von Zertifikaten, die mit der Key Vault-VM-Erweiterung bereitgestellt werden.

    Hinweis

    Das Deaktivieren von Verknüpfung ist eine Eigenschaft der Key Vault-VM-Erweiterung auf oberster Ebene und kann nicht für einzelne beobachtete Zertifikate festgelegt werden.

Warum sollte eine vom Benutzer zugewiesene verwaltete Identität verwendet werden? Welche Auswirkungen hat diese Verwendung?

Wie aus den oben aufgeführten JSON-Codeausschnitten ersichtlich wurde, ist eine bestimmte Abfolge der Vorgänge und Aktualisierungen erforderlich, um sowohl den Erfolg der Konvertierung zu gewährleisten als auch die Verfügbarkeit des Clusters zu erhalten. Insbesondere deklariert und verwendet die Ressource der VM-Skalierungsgruppe ihre Identität, um Geheimnisse (aus der Sicht des Benutzers) in einer einzigen Aktualisierung abzurufen.

Die Service Fabric-VM-Erweiterung (die das Bootstrapping des Clusters durchführt) hängt vom Abschluss der Key Vault-VM-Erweiterung ab, die ihrerseits vom erfolgreichen Abruf der überwachten Zertifikate abhängt.

Die Key Vault-VM-Erweiterung verwendet die Identität einer VM-Skalierungsgruppe für den Zugriff auf den Schlüsseltresor, was bedeutet, dass die Zugriffsrichtlinie für den Schlüsseltresor bereits vor der Bereitstellung der VM-Skalierungsgruppe aktualisiert worden sein muss.

Um über die Erstellung einer verwalteten Identität zu veranlassen oder sie einer anderen Ressource zuzuweisen, muss der Zuständige für die Bereitstellung über die erforderliche Rolle (ManagedIdentityOperator) im Abonnement oder in der Ressourcengruppe verfügen, und zwar zusätzlich zu den Rollen, die für die Verwaltung der anderen in der Vorlage referenzierten Ressourcen erforderlich sind.

Beachten Sie vom Standpunkt der Sicherheit aus, dass die VM bzw. VM-Skalierungsgruppe im Hinblick auf ihre Azure-Identität als Sicherheitsbegrenzung betrachtet wird. Das bedeutet, dass jede Anwendung, die auf der VM gehostet wird, im Prinzip ein Zugriffstoken abrufen kann, das die VM darstellt. Zugriffstoken für verwaltete Identitäten werden vom nicht authentifizierten Instanzmetadaten-Dienstendpunkt abgerufen. Wenn Sie die VM als eine gemeinsam genutzte oder mehrinstanzenfähige Umgebung betrachten, ist diese Methode zum Abrufen von Clusterzertifikaten ggf. nicht geeignet. Es ist jedoch der einzige Bereitstellungsmechanismus, der für das automatische Rollover von Zertifikaten in Frage kommt.

Problembehandlung und häufig gestellte Fragen

F: Wie ist eine programmgesteuerte Registrierung bei einem von Key Vault verwalteten Zertifikat möglich?

Ermitteln Sie den Namen des Ausstellers anhand der Key Vault-Dokumentation, und ersetzen Sie ihn dann im folgenden Skript:

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

F: Was passiert, wenn ein Zertifikat von einem nicht deklarierten oder nicht näher bezeichneten Aussteller ausgestellt wird? Wo kann ich die vollständige Liste der aktiven Aussteller einer bestimmten PKI abrufen?

Wenn in der Zertifikatdeklaration Fingerabdrücke des Ausstellers angegeben sind und der direkte Aussteller des Zertifikats nicht in der Liste der angehefteten Aussteller aufgeführt ist, wird das Zertifikat als ungültig betrachtet, und zwar unabhängig davon, ob sein Stammzertifikat vom Client als vertrauenswürdig eingestuft wird oder nicht. Daher ist es entscheidend sicherzustellen, dass die Liste der Aussteller aktuell ist. Die Einführung eines neuen Ausstellers ist ein seltenes Ereignis und sollte umfassend bekannt gegeben werden, bevor mit der Ausstellung von Zertifikaten begonnen wird.

Im Allgemeinen veröffentlicht und pflegt eine PKI eine Erklärung zum Zertifizierungsbetrieb in Übereinstimmung mit IETF RFC 7382. Neben anderen Informationen enthält die Erklärung alle aktiven Aussteller. Der programmgesteuerte Abruf dieser Liste kann sich je nach PKI unterscheiden.

Bei Microsoft-internen PKIs sollten Sie unbedingt die interne Dokumentation zu den Endpunkten und SDKs zu Rate ziehen, die zum Abrufen der autorisierten Aussteller verwendet werden. Es liegt in der Verantwortung des Clusterbesitzers, diese Liste regelmäßig zu überprüfen, um sicherzustellen, dass seine Clusterdefinition alle erwarteten Aussteller enthält.

F: Werden mehrere PKIs unterstützt?

Ja. Sie dürfen im Clustermanifest nicht mehrere CN-Einträge mit demselben Wert deklarieren, Sie können aber Aussteller aus mehreren PKIs auflisten, die demselben CN entsprechen. Diese Vorgehensweise wird nicht empfohlen, und die Verfahren zur Transparenz von Zertifikaten können das Ausstellen solcher Zertifikate verhindern. Als Maßnahme zur Migration von einer PKI zu einer anderen ist dies jedoch eine akzeptable Lösung.

F: Was geschieht, wenn das aktuelle Clusterzertifikat nicht von einer Zertifizierungsstelle ausgestellt wurde oder nicht den beabsichtigten Antragsteller aufweist?

Beziehen Sie ein Zertifikat mit dem beabsichtigten Antragsteller, und fügen Sie es per Fingerabdruck als sekundär in die Definition des Clusters ein. Nach erfolgreichem Abschluss der Aktualisierung veranlassen Sie eine weitere Aktualisierung der Clusterkonfiguration, um die Zertifikatdeklaration in den allgemeinen Namen zu konvertieren.