View a markdown version of this page

Databricks OAuth Client Secret für Dienstprinzipal - AWS Secrets Manager

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Databricks OAuth Client Secret für Dienstprinzipal

Geheime Wertfelder

Die folgenden Felder müssen im Secrets Manager Manager-Geheimnis enthalten sein:

{ "accountId": "Databricks account UUID", "servicePrincipalId": "Numeric service principal ID", "clientId": "Service principal application UUID", "clientSecret": "dose followed by the secret value", "oauthSecretId": "Hexadecimal OAuth secret ID" }
accountId

Ihre Databricks Konto-ID, bei der es sich um eine UUID handelt.

Dienst PrincipalId

Die numerische interne ID des Dienstprinzipals. Dieser Wert unterscheidet sich von der Anwendungs-ID.

clientId

Die Anwendungs-ID des Dienstprinzipals. Secrets Manager sendet es wie client_id bei OAuth-Anfragen.

Geheimer Client

Das aktuelle geheime OAuth-Clientgeheimnis. Secrets Manager dreht dieses Feld.

OAuth SecretId

Die Databricks ID des aktuellen OAuth-Geheimnisses. Secrets Manager verwendet es, um die Bereiche des aktuellen Geheimnisses zu lesen und das Geheimnis zu löschen, das es ersetzt.

Geheime Metadatenfelder

Im Folgenden sind die Metadatenfelder für Databricks Service Principal OAuth Client Secret aufgeführt:

{ "adminSecretArn": "arn:aws:secretsmanager:us-east-1:111122223333:secret:DatabricksAdminServicePrincipal", "secretLifetimeDays": "730" }
admin SecretArn

(Optional) Der Amazon-Ressourcenname (ARN) eines anderen Geheimnisses vom Typ DataBricksSPSecret, das dieses Geheimnis rotiert. Lassen Sie dieses Feld weg, damit der Service Principal sein eigenes Geheimnis wechseln kann.

geheim LifetimeDays

(Optional) Die Lebensdauer jedes neuen Geheimnisses in Tagen. Der Wert muss größer als Ihr Rotationsintervall sein. Das Maximum ist 730. Standard: 730.

Nutzungsablauf

Dieser Rotationstyp unterstützt zwei Modi. Bei der Eigenrotation wechselt der Dienstprinzipal sein eigenes Geheimnis. Bei der assistierten Rotation wechselt ein zweiter Dienstleiter den Dienst. Der Dienstprinzipal, der die Rotation durchführt, benötigt diese account_admin Rolle, da sich die geheimen OAuth-Endpunkte auf Kontoebene befinden.

Sie können Ihr Geheimnis mithilfe des CreateSecretAufrufs mit dem geheimen Wert, der die oben genannten Felder enthält, und dem Geheimtyp DataBricksSPSecret erstellen. Die Rotationskonfigurationen können mithilfe eines Anrufs festgelegt werden. RotateSecret Wenn Sie sich für die Eigenrotation entscheiden, können Sie das optionale adminSecretArn Feld weglassen. Sie müssen in dem RotateSecretAnruf einen Rollen-ARN angeben, der dem Dienst die erforderlichen Berechtigungen für die Rotation des Secrets gewährt. Ein Beispiel für eine Berechtigungsrichtlinie finden Sie unter Sicherheit und Berechtigungen.

Während der Rotation fordert Secrets Manager mithilfe des Client-Anmeldedatenflusses ein Zugriffstoken an. Es erstellt ein Ersatzgeheimnis, das die Gültigkeitsbereiche des Secrets trägt, das es ersetzt, und speichert das Ersatzgeheimnis als AWSPENDING. Es bestätigt, dass das neue Geheimnis authentifiziert wird. Anschließend wird das vorherige Geheimnis gelöscht und AWSPENDING auf AWSCURRENT heraufgestuft.

Ein Service Principal unterstützt maximal fünf OAuth-Geheimnisse. Wenn der Service Principal bereits fünf besitzt, Databricks lehnt er die Anfrage ab und die Rotation schlägt fehl. Löschen Sie ein unbenutztes Geheimnis, bevor Sie erneut rotieren.

Die account_admin Rolle, die dieser Typ benötigt, unterscheidet sich von dem Workspace-Zugriff, der für die Rotation von Databricks Personal Access Token erforderlich ist. Ein einziger Zuschuss deckt nicht beide Ströme ab.