Oracle Cloud Infrastructure - Dokumentation

Secrets replizieren

Erfahren Sie mehr über das regionsübergreifende Replizieren von Secrets.

Sie können Secrets aus den folgenden Gründen regionsübergreifend replizieren:

  • Disaster Recovery: Durch das Replizieren von Secrets wird deren Zugänglichkeit bei regionalen Unterbrechungen sichergestellt. Systeme mit Standby-, Failover- und Switchover-Funktionen benötigen möglicherweise Secrets, die für Standby-Systeme verfügbar sind.
  • Verfügbarkeit: Wenn Sie ein Secret in mehreren Regionen verwenden, erleichtert die Replikation des Secrets in zusätzlichen Regionen den Zugriff auf das Secret und die Aktualisierung in den Regionen, in denen es benötigt wird. Achten Sie darauf, die Sicherheitsrichtlinien Ihrer Organisation bezüglich der Verwendung eines Secrets in mehreren Regionen zu befolgen.

Funktionsweise der Replikation

Wenn Sie ein Secret in einem Vault erstellen, haben Sie die Möglichkeit, das Secret in bis zu 3 anderen Regionen zu replizieren. Sie können die Replikation auch aktivieren, nachdem Sie ein Secret erstellt haben, indem Sie das Secret bearbeiten. Wenn Sie Replikate eines Secrets erstellen, geben Sie die Zielregion, den Ziel-Vault in dieser Region und den Verschlüsselungsschlüssel an, der für das Secret verwendet werden soll. Die Replikatsecrets und Secret-Versionen verwenden dieselben OCIDs wie die Quell-Secret- und Secret-Versionen. Replikat-Secrets werden zusammen mit Quell-Secrets für die regionalen Limits Ihres Mandanten für Secrets gezählt.

Beim Aktivieren der Replikation repliziert OCI Folgendes:

  • Der geheime Inhalt
  • Metadaten und Einstellungen des Secrets
  • Secret-Versionen

Das Replikat ist schreibgeschützt und kann nicht bearbeitet werden. Wenn Sie ein Quell-Secret bearbeiten oder löschen, wird der Änderungs- oder Löschvorgang auch auf die Replikate des Secrets angewendet. Wenn Sie die Funktion in einem Secret mit Replikaten deaktivieren, werden die Replikate gelöscht. Sie können Replikate auch einzeln löschen, während Sie das Quell-Secret beibehalten, indem Sie das Quell-Secret bearbeiten.

Mit Arbeitsanforderungen können Sie den Fortschritt der regionsübergreifenden Replikationsvorgänge überwachen. Weitere Informationen zur Verwendung von Arbeitsanforderungen mit dem Secret-Service finden Sie unter Secret-Arbeitsanforderungen.

Verwenden Sie die folgenden Anweisungen, um Secret-Replikate zu verwalten:

Wichtig

Secrets werden bei der Vault-Replikation nicht automatisch repliziert. Sie müssen die Secret-Replikation auf der Ebene der Secret-Ressource verwalten. Informationen zur Vault-Replikation finden Sie unter Vaults und Schlüssel replizieren.

Write Forwarding für Aktualisierungsvorgänge an Replikat-Secrets

Optional können Sie "Write Forwarding" für replizierte Secrets mit der API oder CLI aktivieren. Während replizierte Secrets schreibgeschützt sind, können Sie mit der Schreibweiterleitung ein repliziertes Secret für einen Schreibvorgang als Ziel festlegen und den Vorgang zuerst automatisch auf das Quell-Secret und dann über asynchrone Updates auf alle Replikate des Quell-Secrets anwenden.

Beispiel: Wenn Sie ein Quellgeheimnis in der Region "US East (Ashburn)" haben, das in der Region "Japan East (Tokio)" repliziert wird, können Sie das Replikatgeheimnis in "Japan East (Tokio)" auf ein Update ausrichten. Die Aktualisierungsanforderung wird dann an das Quell-Secret in US East (Ashburn) weitergeleitet und automatisch an diesem Secret ausgeführt. Nachdem das Quell-Secret aktualisiert wurde, wird die Aktualisierungsanforderung automatisch auf alle Replikate des Quell-Secrets angewendet, einschließlich des Replikats in Japan East (Tokio).

Einschränkungen

Die folgenden Einschränkungen gelten für die Schreibweiterleitungsfunktion, um die Sicherheit und Sicherheit von Secrets zu gewährleisten:

  • Für die folgenden Vorgänge können Sie keine Schreibweiterleitung verwenden:

    • Secret-Löschung planen
    • Löschen eines Secrets abbrechen
    • Replikationskonfiguration des Quell-Secrets aktualisieren
  • Wenn Sie ein neues Secret erstellen, können Sie die Schreibweiterleitung aktivieren. Sie können jedoch nicht den Vault einer Remoteregion angeben, der das Quell-Secret mit der Schreibweiterleitungsfunktion enthält.
  • Da der Schreibvorgang asynchron erfolgt und Updates zuerst auf das Quell-Secret angewendet werden, erwarten Sie eine Verzögerung zwischen dem Start der Aktualisierung auf dem Replikat und dem Abschluss der Aktualisierung in der Region des Replikats. Sie können den Fortschritt Ihres Updates mit Arbeitsanforderungen überwachen. Weitere Informationen zur Verwendung von Arbeitsanforderungen mit dem Secret-Service finden Sie unter Secret-Arbeitsanforderungen.
  • Die Entity, die das Update in der Region des Replikats anfordert, muss autorisiert sein, die Aktualisierung in der Region des Quell-Secrets und in der Region auszuführen, in der sich das Replikat befindet.
  • Sie können die Schreibweiterleitung nicht in der OCI-Konsole aktivieren. Verwenden Sie die APIs CreateSecret und UpdateSecret oder die CLI-Befehle für diese Vorgänge, um die Schreibweiterleitung zu aktivieren. Setzen Sie in den APIs isWriteForwardEnabled auf true, um das Feature zu aktivieren.

Erforderliche IAM-Policy

Mit den Berechtigungsinformationen in diesem Abschnitt können Benutzer oder Resource Principals die regionsübergreifende Replikation von Secrets konfigurieren.

Erforderliche Berechtigungen zum Konfigurieren der Replikation

Um eine Secret-Replikationskonfiguration (replicationConfig) zu erstellen oder zu aktualisieren, muss ein Benutzer oder Resource Principal über die Berechtigung SECRET_REPLICATE_CONFIGURE verfügen. Dies ist im Verb manage secrets enthalten.

Um ein Secret mit aktivierter Replikation zu erstellen, stellen Sie sicher, dass Sie oder der Resource Principal über die folgenden Berechtigungen verfügen:

  • SECRET_CREATE, KEY_ENCRYPT, KEY_DECRYPT, VAULT_CREATE_SECRET (zur Verwendung der API CreateSecret oder zum Erstellen von Secrets in der Konsole oder anderen Schnittstellen).
  • SECRET_REPLICATE_CONFIGURE

Um eine Replikationskonfiguration zu aktualisieren (oder zu entfernen), stellen Sie sicher, dass Sie oder der Resource Principal über die folgenden Berechtigungen verfügen:

  • SECRET_UPDATE (zur Verwendung der API UpdateSecret oder zum Aktualisieren von Secrets in der Konsole oder anderen Schnittstellen).
  • SECRET_REPLICATE_CONFIGURE

Beispiel-Policy

Die folgende Beispiel-Policy enthält Anweisungen, die alle Ressourcen abdecken, die für die regionsübergreifende Replikation für neue oder vorhandene Secrets erforderlich sind:

Allow group Admins to manage secrets in compartment CompartmentName # for granting SECRET_CREATE, SECRET_UPDATE, SECRET_REPLICATE_CONFIGURE
Allow group Admins to use keys in compartment CompartmentName       # for granting KEY_ENCRYPT, KEY_DECRYPT
Allow group Admins to use vaults in compartment CompartmentName     # for granting VAULT_CREATE_SECRET
Hinweis

Die Authentifizierungsverben in der Beispiel-Policy (manage secrets, use keys, use vaults) enthalten auch weitere Berechtigungen, die in diesem Thema nicht aufgeführt sind. Prüfen Sie Details für Kombinationen aus Verb und Ressourcentyp, wenn Sie IAM-Policys für Secrets schreiben.

Von Resource Principals benötigte Berechtigungen zur regionsübergreifenden Secret-Replikation

Wenn die Replikation in einem Secret aktiviert ist, müssen Sie dem Resource Principal relevante Berechtigungen im Kontext der Zielregion erteilen, damit die Replikation erfolgen kann.

Dynamische Gruppen einrichten

Es wird empfohlen, eine dynamische Gruppe für die Secrets einzurichten, die Sie replizieren, um das Policy-Management zu vereinfachen. Beispiel für eine Vergleichsregel:

All {resource.type = 'vaultsecret', resource.compartment.id = '<compartment ID>'}

Weitere Informationen zu Übereinstimmungsregeln für dynamische Gruppen finden Sie unter Zuordnungsregeln zum Definieren dynamischer Gruppen schreiben.

Policy erstellen

Bei der Secret-Replikation muss der zu Ihrem Secret gehörende vaultsecret-Resource Principal über Berechtigungen zum Erstellen und Verwalten des Replikat-Secrets in der Zielregion verfügen. Diese Berechtigungen sind SECRET_CREATE, KEY_ENCRYPT, KEY_DECRYPT, VAULT_CREATE_SECRET und SECRET_REPLICATE.

Beachten Sie, dass SECRET_REPLICATE eine Berechtigung ist, die nur für das Feature für die regionsübergreifende Replikation verwendet wird. Wenn SECRET_REPLICATE erteilt wird, kann ein vaultsecret-Resource Principal ein Replikat in der Zielregion erstellen.

Beispiel-Policy für Resource Principal für Vaultsecret

Allow dynamic-group VaultSecretDG to use secret-replication in compartment CompartmentName # for granting SECRET_REPLICATE
Allow dynamic-group VaultSecretDG to manage secrets in compartment CompartmentName         # for granting SECRET_CREATE
Allow dynamic-group VaultSecretDG to use vaults in compartment CompartmentName             # for granting VAULT_CREATE_SECRET
Allow dynamic-group VaultSecretDG to use keys in compartment CompartmentName               # for granting KEY_ENCRYPT, KEY_DECRYPT
Hinweis

  • Die Authentifizierungsverben in der Beispiel-Policy (manage secrets, use keys, use vaults) enthalten auch weitere Berechtigungen, die in diesem Thema nicht aufgeführt sind. Prüfen Sie Details für Kombinationen aus Verb und Ressourcentyp, wenn Sie IAM-Policys für Secrets schreiben.
  • Diese Berechtigungen müssen im Kontext der Zielregion erteilt werden. Beispiel: Wenn Sie den Zugriff mit der Kontextvariable für die Vault-ID einschränken, stellen Sie sicher, dass die angegebene Variable die Vault-ID der Zielregion ist.
  • Wenn Ihr Compartment oder Secret definierte Tags verwendet, stellen Sie sicher, dass Sie der dynamischen Gruppe "vaultsecret" auch die Berechtigung use tag-namespaces erteilen.