Rotationspläne

In diesem Thema wird das Konzept der Secrets-Rotation vorgestellt. Bevor Sie beginnen, sollten Sie sich die Plattformübersicht ansehen, um sich mit den Zusammenhängen der gesamten Google Cloud-Landschaft vertraut zu machen. Wir empfehlen Ihnen auch, die Produktübersicht zu Secret Manager zu lesen.

Einleitung

Regelmäßige Rotation hilft bei Folgendem:

  • Auswirkungen im Fall eines gehackten Secrets begrenzen
  • Achten Sie darauf, dass Personen, die keinen Zugriff mehr auf ein Secret benötigen, keine alten Secret-Werte verwenden können.
  • Kontinuierlich den Rotationsworkflow ausführen, um die Wahrscheinlichkeit eines Ausfalls bei einer Notfallrotation zu reduzieren

Secret Manager hat ein Konzept von Secrets, Secret-Versionen und Rotationsplänen, das eine Basis für die Erstellung von Arbeitslasten bietet, die rotierte Secrets unterstützen.

In diesem Thema finden Sie Empfehlungen für das Rotieren von Secrets in Secret Manager. In den nächsten Abschnitten werden die Vor- und Nachteile für Folgendes erläutert:

Bindung an eine Secret-Version vornehmen

Ein Secret in Secret Manager kann mehrere Secret-Versionen haben. Secret-Versionen enthalten die unveränderliche Nutzlast (den Secret-Bytestring) und sind geordnet und nummeriert. Fügen Sie eine neue Secret-Version zu einem vorhandenen Secret hinzu, um ein Secret zu rotieren.

Die zuletzt hinzugefügte Secret-Version für ein Secret kann mit dem Alias latest referenziert werden. Der Alias latest ist zwar für die Entwicklung praktisch, kann aber für einige Produktionsarbeitslasten problematisch sein, da ein ungültiger Wert sofort eingeführt werden und zu einem Ausfall des Dienstes führen kann. In den folgenden Szenarien werden alternative Methoden zur Bindung an eine Secret-Version beschrieben.

Graduelle Roll-outs

Graduelle Roll-outs sind ein Leitprinzip für die folgenden Szenarien. Durch die Wahl eines langsameren Secret-Roll-outs ist das Risiko eines Ausfalls, aber die Zeit für die Wiederherstellung ist auch länger. Einige Secrets können in externen Systemen (z. B. APIs oder Datenbanken, die gültige Secret-Werte verfolgen) ungültig werden, über die Sie nicht unbedingt die Kontrolle haben, und eine Wiederherstellung erfordert in diesen Fällen einen Roll-out.

Es kann sein, dass ein ungültiges Secret entweder während der manuellen oder der automatischen Rotation eingeführt wird. Ein starker Rotationsworkflow sollte den Ausfall (z. B. HTTP-Fehlerraten) automatisch erkennen und ein Rollback zur Verwendung der älteren Secret-Version (über eine vorherige Konfigurationsbereitstellung) ermöglichen.

Der Roll-out der neuen Secret-Version hängt davon ab, wie Secrets an Ihre Anwendung gebunden sind.

Ansatz 1: Während eines vorhandenen Releaseprozesses auflösen

Führen Sie die Auflösung und Bindung Ihrer Secret-Version bei der Veröffentlichung der Anwendung durch. Bei den meisten Bereitstellungen muss dafür die neueste Secret-Version in den vollständigen Ressourcennamen der Secret-Version aufgelöst und mit der Anwendung als Flag oder in einer Konfigurationsdatei eingeführt werden. Wir empfehlen, den Namen der Secret-Version zum Zeitpunkt der Rotation aufzulösen, den Ressourcennamen an einem langlebigen Ort zu speichern (z. B. durch einen Commit an Git) und den Versionsnamen während der Push-Übertragung in die Bereitstellungskonfiguration zu übertragen, um zu verhindern, dass Bereitstellungen blockiert werden.

Rufen Sie beim Start der Anwendung Secret Manager mit dem spezifischen Secret-Versionsnamen auf, um auf den Secret-Wert zuzugreifen.

Dieser Ansatz bietet folgende Vorteile:

  • Ihre Anwendung verwendet bei Neustarts dieselbe Secret-Version, wodurch die Planbarkeit verbessert und die operative Komplexität verringert wird.
  • Vorhandene Änderungsmanagement-Prozesse für Roll-outs und Rollbacks können für die Secret-Rotation und die Bereitstellung der Secret-Version wiederverwendet werden.
  • Der Wert kann schrittweise eingeführt werden, um die Auswirkungen von fehlerhaften Werten zu reduzieren.

Ansatz 2: Beim Start der Anwendung auflösen

Rufen Sie beim Start der Anwendung die neueste Secret-Nutzlast ab und verwenden Sie das Secret für die Dauer der Anwendung weiter.

Der Vorteil dieses Ansatzes besteht darin, dass die CI/CD-Pipeline nicht geändert werden muss, um Secret-Versionen aufzulösen. Wenn jedoch ein fehlerhaftes Secret eingeführt wird, kann die Anwendung nicht neu gestartet werden, wenn Instanzen neu gestartet werden oder der Dienst hochskaliert wird, was zu einem Dienstausfall führen kann.

Ansatz 3: Kontinuierlich auflösen

Fragen Sie kontinuierlich die neueste Secret-Version in der Anwendung ab und verwenden Sie den neuen Secret-Wert sofort.

Dieser Ansatz birgt die Gefahr unmittelbarer, dienstweiter Ausfälle, da der neue Secret-Wert nicht schrittweise übernommen wird.

Secret rotieren

Wenn Ihr Secret dynamisch aktualisiert werden kann (z. B. wenn das externe System, das das Secret validiert, eine Admin API bereitstellt), empfehlen wir die Einrichtung eines regelmäßig ausgeführten Rotationsjobs. Die allgemeinen Schritte werden im folgenden Abschnitt mit Cloud Run als Beispiel-Computing-Umgebung beschrieben.

Rotationsplan für Ihr Secret konfigurieren

Richten Sie einen Rotationsplan für Ihr Secret ein. Pub/Sub-Themen müssen für das Secret konfiguriert werden, um Benachrichtigungen zu erhalten, wenn es an der Zeit ist, das Secret zu rotieren. Weitere Informationen zum Konfigurieren von Themen für Ihre Secrets finden Sie unter Ereignisbenachrichtigungen.

Cloud Run starten, um eine neue Secret-Version zu erstellen

Erstellen und konfigurieren Sie einen Cloud Run-Dienst, um Rotationsbenachrichtigungen zu erhalten und Rotationsschritte auszuführen:

  1. Rufen Sie ein neues Secret im externen System ab (z. B. Datenbank oder API-Anbieter) oder erstellen Sie eines.

    Achten Sie darauf, dass vorhandene Secrets nicht ungültig werden, damit vorhandene Arbeitslasten nicht beeinträchtigt werden.

  2. Aktualisieren Sie Secret Manager mit dem neuen Secret.

    Erstellen Sie eine neue SecretVersion in Secret Manager. Dadurch wird auch der Alias latest aktualisiert, sodass er auf das neu erstellte Secret verweist.

Wiederholungsversuche und Nebenläufigkeit

Da Ihr Rotationsprozess jederzeit beendet werden kann, muss Ihr Cloud Run-Dienst den Prozess von der Stelle aus fortsetzen können, an der er unterbrochen wurde.

Wir empfehlen, Wiederholungsversuche in Pub/Sub zu konfigurieren, damit fehlgeschlagene oder unterbrochene Rotationen noch einmal ausgeführt werden können. Konfigurieren Sie außerdem die maximale Nebenläufigkeit und die maximale Anzahl von Instanzen für Ihren Cloud Run-Dienst, um die Wahrscheinlichkeit zu minimieren, dass sich nebenläufige Rotationsausführungen gegenseitig beeinträchtigen.

Für die Erstellung einer fortsetzbaren Rotationsfunktion ist es möglicherweise hilfreich, den Zustand zu speichern, damit der Rotationsprozess fortgeführt werden kann. Es gibt zwei Secret Manager-Features, die dabei helfen:

  • Verwenden Sie Labels für Secrets, um den Zustand während der Rotation zu speichern. Fügen Sie dem Secret ein Label hinzu, um die Anzahl der zuletzt erfolgreich hinzugefügten Version während des Rotationsworkflows zu verfolgen (d. h. ROTATING_TO_NEW_VERSION_NUMBER=3). Entfernen Sie nach der Rotation das Label für das Rotations-Tracking.
  • Verwenden Sie ETags, um zu kontrollieren, dass andere Prozesse das Secret während des Rotationsworkflows nicht gleichzeitig ändern. Weitere Informationen finden Sie unter ETags für Secrets und Secret-Versionen.

IAM-Berechtigungen (Identity and Access Management)

Für Ihren Rotationsprozess ist die Berechtigung secretmanager.versions.add erforderlich, um eine neue Secret-Version hinzuzufügen, und möglicherweise secretmanager.versions.access, um die vorherige Secret-Version zu lesen.

Das Cloud Run-Standarddienstkonto hat die Rolle Bearbeiter, die die Berechtigung zum Hinzufügen, aber nicht zum Abrufen der Secret-Versionen enthält. Zur Beachtung des Prinzips der geringsten Berechtigung empfehlen wir, KEIN Standarddienstkonto zu verwenden. Richten Sie stattdessen ein separates Dienstkonto für Ihren Cloud Run-Dienst ein, wobei die Secret Manager-Rollen nach Bedarf zugewiesen werden. Dies können eine oder mehrere der folgenden sein:

  • roles/secretmanager.secretVersionAdder
  • roles/secretmanager.secretVersionManager
  • roles/secretmanager.secretAdmin
  • roles/secretmanager.secretAccessor

Neue SecretVersion für Arbeitslasten einführen

Nachdem eine neue, gültige SecretVersion beim externen System registriert und in Secret Manager gespeichert wurde, führen Sie sie für Ihre Anwendung ein. Dieser Roll-out variiert je nach dem Ansatz für die Secret-Bindung (siehe Abschnitt Bindung an eine Secret-Version vornehmen) und erfordert im Allgemeinen keine manuelle Eingriffe.

Alte Secret-Versionen bereinigen

Nachdem alle Anwendungen von der alten Secret-Version wegrotiert wurden, kann sie sicher bereinigt werden. Der Bereinigungsprozess hängt vom Typ des Secrets ab, aber im Allgemeinen müssen Sie Folgendes tun:

  1. Prüfen Sie, ob die neue Secret-Version vollständig für alle Anwendungen eingeführt wurde.
  2. Deaktivieren Sie die alte Secret-Version in Secret Manager und stellen Sie sicher, dass die Anwendungen nicht unterbrochen werden (warten Sie eine angemessene Zeit, bis ein Mitarbeiter eingreifen kann, falls die Deaktivierung einen Nutzer beeinträchtigt).
  3. Entfernen Sie die alten Secret-Version vom externen System oder heben Sie die Registrierung dort auf.
  4. Löschen Sie die alte Secret-Version in Secret Manager.

Nächste Schritte