Rotieren von Kubernetes-Zertifikaten mithilfe der AKS-Engine in Azure Stack Hub

  • Artikel

Dieses Dokument enthält Anleitungen zum Rotieren von Zertifikaten in einem vorhandenen AKS-Engine-Cluster sowie Empfehlungen für die Verwendung von aks-engine rotate-certs als Tool.

Voraussetzungen

In dieser Anleitung wird davon ausgegangen, dass Sie bereits einen Cluster mit der AKS-Engine bereitgestellt haben und sich der Cluster in einem fehlerfreien Zustand befindet.

Planen der Zertifikatrotation

Beachten Sie bei Verwendung dieser Funktion, dass die Kubernetes-Steuerungsebene während der Schritte zur Aktualisierung, Prüfung und zum Neustart nicht verfügbar ist. Berücksichtigen Sie dies bei der Planung des Wartungsvorgangs. Planen Sie außerdem ein, diesen Vorgang vor der Ausführung in der Produktionsumgebung erst in einer Stagingumgebung mit identischer Konfiguration auszuführen.

Befassen Sie sich mit den folgenden Überlegungen, bevor Sie diesen Vorgang ausführen:

Hinweis

Für AKSe Version 0.75.3 und höher beginnen die Befehle für die Zertifikatrotation mit aks-engine-azurestack anstelle aks-enginevon .

  • Sie benötigen Zugriff auf das API-Modell (apimodel.json), das mit dem Befehl aks-engine deploy oder aks-engine generate generiert wurde. Diese Datei wird standardmäßig in einem relativen Verzeichnis platziert, z. B. _output/<clustername>/.

  • Ein aks-engine rotate-certs-Vorgang verursacht Ausfallzeiten beim API-Server.

  • aks-engine rotate-certs erwartet ein API-Modell, das dem aktuellen Zustand des Clusters entspricht. aks-engine rotate-certs führt Remotebefehle auf den Clusterknoten aus und verwendet die API-Modellinformationen, um eine sichere SSH-Verbindung herzustellen. Für aks-engine rotate-certs ist es außerdem erforderlich, dass einige Ressourcen wie in der ursprünglichen aks-engine-Bereitstellung benannt werden. Beispielsweise müssen die Namen der VMs der durch aks-engine vorgegebenen Benennung entsprechen.

  • aks-engine rotate-certs verlangt während der Zertifikatrotation eine funktionierende Verbindung mit der Clustersteuerungsebene:

    • Zum Überprüfen der einzelnen Schritte des Vorgangs.
    • Zum Neustarten/Neuerstellen von Clusterressourcen wie kube-system-Pods und Dienstkontotoken.

    Wenn Sie die Zertifikate eines Clusters in einem VNet rotieren, auf das von außerhalb kein Zugriff möglich ist, müssen Sie aks-engine rotate-certs von einer Host-VM ausführen, die über Netzwerkzugriff auf die Steuerungsebene verfügt, z. B. eine Jumpbox-VM, die sich im gleichen VNet wie die Master-VMs befindet.

  • Wenn Sie aks-engine rotate-certs in der Produktion verwenden, empfiehlt es sich, einen Stagingtest für die Zertifikatrotation in einem Cluster durchzuführen, der mit denselben Spezifikationen erstellt wurde. Das heißt, der Cluster wird mit der gleichen Clusterkonfiguration, derselben Version des AKS-Engine-Befehlszeilentools und den gleichen aktivierten Add-Ons wie der Produktionscluster erstellt, bevor die Zertifikatrotation durchgeführt wird. Die AKS-Engine unterstützt verschiedene Clusterkonfigurationen, und das Ausmaß von End-to-End-Tests, die das AKS-Engine-Team ausführt, kann nicht praktisch jede mögliche Konfiguration abdecken. Daher wird empfohlen, dass Sie anhand einer Stagingumgebung sicherstellen, dass Ihre spezifische Clusterkonfiguration mit aks-engine rotate-certs funktioniert, bevor Sie den Vorgang in Ihrem Produktionscluster ausführen.

  • Die Abwärtskompatibilität von aks-engine rotate-certs ist nicht gewährleistet. Wenn Sie die AKS-Engine-Version 0.60.x bei der Bereitstellung verwendet haben, sollte der Zertifikatrotationsprozess vorzugsweise mit Version 0.60.x ausgeführt werden.

  • Das Abrufen eines neuen Zertifikatsatzes aus Key Vault wird derzeit nicht unterstützt.

  • Verwenden Sie eine zuverlässige Netzwerkverbindung. aks-engine rotate-certs erfordert die Ausführung mehrerer Remotebefehle, bei denen Fehler auftreten können, insbesondere wenn die Verbindung mit den Clusterknoten nicht zuverlässig ist. Durch Ausführen von aks-engine rotate-certs von einer VM, die auf dem Ziel-Azure Stack-Stempel ausgeführt wird, lässt sich das Auftreten vorübergehender Probleme verringern.

Parameter

Parameter Erforderlich BESCHREIBUNG
--api-model ja Relativer Pfad zum API-Modell (Clusterdefinition), das die erwartete Clusterkonfiguration deklariert.
--ssh-host ja Vollqualifizierter Domänenname (Fully Qualified Domain Name, FQDN) oder IP-Adresse eines SSH-Listeners, der alle Knoten im Cluster erreichen kann.
--linux-ssh-private-key ja Pfad zu einem gültigen privaten SSH-Schlüssel für den Zugriff auf die Linux-Knoten des Clusters.
--location ja Azure-Standort, an dem der Cluster bereitgestellt wird.
--subscription-id ja Azure-Abonnement für die Bereitstellung der Clusterinfrastruktur.
--resource-group ja Azure-Ressourcengruppe für die Bereitstellung der Clusterinfrastruktur.
--client-id unterschiedlich Die Client-ID des Dienstprinzipals. Erforderlich, wenn auth-method auf client_secret oder client_certificate festgelegt ist.
--client-secret unterschiedlich Das Clientgeheimnis für den Dienstprinzipal. Erforderlich, wenn auth-method auf client_secret festgelegt ist.
--azure-env unterschiedlich Der Name der Zielcloud. Optional, wenn AzureCloud die Zielcloud ist.
--certificate-profile nein Relativer Pfad zu einer JSON-Datei, die den neuen Zertifikatsatz enthält.
--force nein Ausführung wird erzwungen, auch wenn der API-Server nicht reagiert.

Einfache Schritte zum Rotieren von Zertifikaten

Führen Sie für AKS Engine-Versionen 0.75.3 und höher mit den entsprechenden Argumenten aus,nachdem aks-engine-azurestack rotate-certs Sie alle Anforderungen gelesen haben (siehe unten).

Führen Sie für AKS Engine-Versionen 0.73.0 und höher mit den entsprechenden Argumenten ausaks-engine rotate-certs, nachdem Sie alle Anforderungen gelesen haben:

./bin/aks-engine rotate-certs \
  --location <resource-group-location> \
  --api-model <generated-apimodel.json> \
  --linux-ssh-private-key <private-SSH-key> \
  --ssh-host <apiserver-URI> \
  --resource-group <resource-group-name> \
  --client-id <service-principal-id> \
  --client-secret <service-principal-secret> \
  --subscription-id <subscription-id> \
  --azure-env <cloud-name>

Beispiel:

./bin/aks-engine rotate-certs \
  --location "westus2" \
  --api-model "_output/my-cluster/apimodel.json" \
  --linux-ssh-private-key "~/.ssh/id_rsa" \
  --ssh-host "my-cluster.westus2.cloudapp.azure.com"\
  --resource-group "my-cluster" \
  --client-id "12345678-XXXX-YYYY-ZZZZ-1234567890ab" \
  --client-secret "12345678-XXXX-YYYY-ZZZZ-1234567890ab" \
  --subscription-id "12345678-XXXX-YYYY-ZZZZ-1234567890ab" \
  --azure-env "AzureStackCloud" # optional if targeting AzureCloud

Rotieren von front-proxy-Zertifikaten

Hinweis

Für AKSe Version 0.75.3 und höher beginnen die Befehle für die Zertifikatrotation mit aks-engine-azurestack anstelle aks-enginevon .

Die AKS-Engine erstellt im Rahmen des Bootstrappingprozesses für Knoten eine separate PKI für front-proxy und stellt sie über etcd für alle Knoten bereit. Damit diese Funktionalität effektiv wiederverwendet werden kann, müssen die in etcd gespeicherten Zertifikate durch rotate-certs ersetzt werden. Die front-proxy-Zertifikate laufen nach 30 Jahren ab. aks-engine rotate-certs rotiert die front-proxy-Zertifikate.

Problembehandlung

Hinweis

Für AKSe Version 0.75.3 und höher beginnen die Befehle für die Zertifikatrotation mit aks-engine-azurestack anstelle aks-enginevon .

Wenn der Zertifikatrotationsprozess aufgrund eines Fehlers oder vorübergehenden Problems (z. B. mit der Netzwerkverbindung) vor dem Abschluss angehalten wird, kann aks-engine rotate-certs gefahrlos mit dem Flag --force erneut ausgeführt werden.

Beachten Sie auch, dass aks-engine rotate-certs die Ausgabe der einzelnen Schritte in der Datei /var/log/azure/rotate-certs.log (Linux) bzw. c:\\k\\rotate-certs.log (Windows) protokolliert.

Weitere Informationen zu den Vorgängen im Hintergrund und zur weiteren Anpassung finden Sie in Under the Hood (Hinter den Kulissen, in englischer Sprache).

Nächste Schritte