Workspace-IP-Zugriffslisten auf kontextbasierten Eingang migrieren

Workspace-IP-Zugriffslisten beschränken den Zugriff ausschließlich auf Quell-IP-Adressen. Kontextbasierte Ingress-Kontrollen ermöglichen es Kontoadministratoren, Regeln basierend auf mehreren Bedingungen zu erstellen, darunter Benutzeridentität, Anforderungstyp und Netzwerkquelle. Dies bietet eine detailliertere Kontrolle darüber, wer Ihren Arbeitsplatz erreichen kann und von wo.

Databricks empfiehlt, kontextbasierte Eingänge als primäre Kontrolle für den Arbeitsbereichseingang zu verwenden. Für einen Überblick darüber, wie kontextbasierter Ingress Anfragen bewertet, siehe Kontextbasierte Ingress-Kontrolle.

Sie können das CLI-Tool von Databricks Labs migrate-ip-acls verwenden, um bestehende IP-Zugriffslisten im Arbeitsbereich auf eine kontextbasierte Ingress-Policy zu migrieren.

Requirements

• Du musst ein Workspace-Admin für den Workspace sein, den du migriert. Das Lesen von IP-Zugriffslisten für Arbeitsbereiche erfordert Workspace-Administratorrechte.
• Du musst ein Kontoadministrator sein. Das Erstellen und Anhängen von Netzwerkrichtlinien erfordert Account-Admin-Berechtigungen.

• Kontextbasierter Einstieg erfordert die Premium-Stufe.

Überprüfen Sie die Einschränkungen des Migrationstools , bevor Sie beginnen, denn das Tool kann nicht jeden Arbeitsbereich migrieren.

Wie das Migrationstool funktioniert

Das Migrationstool führt folgende Schritte durch:

1. Authentifiziert sich beim ausgewählten Arbeitsbereich mit deinen Admin-Rechten im Arbeitsbereich und beim Azure Databricks-Konto mit den Administratorrechten deines Kontos.
2. Führt Vormigrationsprüfungen durch, um festzustellen, ob der Arbeitsbereich sicher migriert werden kann.
3. Sie bitten Sie, einen Richtliniennamen für die generierte Netzwerkrichtlinie anzugeben.
4. Liest die aktivierten IP-Zugriffslisten des Arbeitsbereichs aus.
   1. Jede aktivierte Zulassungsliste wird in der generierten Netzwerkrichtlinie in eine kontextbasierte Ingress-Zulassungsregel umgewandelt.
   2. Jede aktivierte Blockliste wird in der generierten Netzwerkrichtlinie in eine kontextbasierte Ingress Deny-Regel umgewandelt.
   3. Bestehende IP-Zugriffslistenlabels werden erhalten.
   4. Listen über behinderte Personen werden nicht migriert und zur Überprüfung gemeldet.
   5. Wenn der Arbeitsbereich nur Sperrlisten hat, fügt das Tool eine allgemeine Zulassungsregel hinzu, sodass die generierte kontextbasierte Eingangsrichtlinie das bestehende Verhalten der IP-Zugriffsliste beibehält.
5. Kopiert die Egress-Konfiguration aus der Netzwerkrichtlinie, die dem Arbeitsbereich derzeit zugeordnet ist, in die generierte Netzwerkrichtlinie. Wenn dem Arbeitsbereich keine ausdrücklich zugewiesene Richtlinie zugeordnet ist, verwendet das Tool die Basisrichtlinie des Kontos default-policy.
6. Zeigt die generierte Netzwerkrichtlinie zur Überprüfung an.
7. Wenn mit --exportkonfiguriert, schreibt das Tool JSON- und Terraform-Darstellungen der vorgeschlagenen Politik.
8. Wenn --create-policy aktiviert, erstellt das Tool die neue Netzwerkrichtlinie.
9. Wenn --auto-assign aktiviert, hängt das Tool die generierte Richtlinie an den ausgewählten Arbeitsbereich an. Da ein Arbeitsbereich eine Netzwerkrichtlinienzuweisung hat, ersetzt diese die vorherige Richtlinienzuweisung des Arbeitsbereichs.
10. Wenn --disable-existing-ip-acls angegeben wird, deaktiviert das Tool die Durchsetzung der IP-Zugriffsliste für den Arbeitsbereich, nachdem die neue erzwungene Richtlinie erfolgreich erstellt und zugewiesen wurde. Die bestehenden IP-Zugriffslisten werden erhalten, aber nicht mehr durchgesetzt.

--auto-assign ist standardmäßig aktiviert. --disable-existing-ip-acls ist standardmäßig deaktiviert.

Während die IP-Zugriffslisten für den Arbeitsbereich aktiviert bleiben, werden sie weiterhin zusammen mit kontextbasiertem Ingress ausgewertet. Eine Anfrage muss beide Kontrollen erfüllen.

Nutzen Sie das Migrationstool

Befolgen Sie diese Schritte, um eine kontextbasierte Ingress-Policy aus den IP-Zugriffslisten eines Arbeitsbereichs zu generieren und sie optional zu erstellen und anzuhängen.

Klonen Sie das Migrationswerkzeug

Klone das Databricks Labs Migrations-Werkzeug-Repository:

git clone https://github.com/databrickslabs/migrate-ip-acls.git
cd migrate-ip-acls

Installieren Sie die Abhängigkeiten des Tools:

uv sync

Melde dich als Workspace-Administrator im Workspace an

Das Lesen und Ändern von IP-Zugriffslisten für Arbeitsbereiche erfordert Administratorrechte für Arbeitsbereiche.

Authentifizieren Sie sich im Arbeitsbereich, indem Sie folgenden Befehl ausführen:

databricks auth login \
   --host https://adb-<WORKSPACE_URL>.azuredatabricks.net/

Der Authentifizierungsbefehl erstellt ein Azure Databricks CLI-Profil für den Arbeitsbereich. Dieses Profil verwenden Sie, wenn Sie das Migrationstool ausführen.

Authentifiziere dich als Kontoadministrator auf das Konto

Das Erstellen und Zuweisen von Netzwerkrichtlinien erfordert Administratorrechte für das Konto.

Authentifizieren Sie sich beim Konto, indem Sie folgenden Befehl ausführen:

databricks auth login \
   --host https://accounts.azuredatabricks.net \
   --account-id <ACCOUNT_ID>

Verwenden Sie das Konto, das den Arbeitsbereich enthält, den Sie migrieren.

Starte das Migrationstool

Starten Sie das Migrationstool, indem Sie folgenden Befehl ausführen:

uv run dbx-migrate-ip-acls --profile <my-workspace-profile-name> --account-id <acct-id> --export .

Eingabeparameter

Das Werkzeug lehnt Parameterkombinationen ab, die dazu führen könnten, dass der Arbeitsbereich nach der Migration eine andere Ingress-Richtlinie aufweist. Zum Beispiel kann --disable-existing-ip-acls nur verwendet werden, wenn das Tool auch eine erzwungene Netzwerkrichtlinie erstellt und anfügt. Sie lehnt auch unsinnige Kombinationen wie --no-create-policy --auto-assign ab.

Ausgaben inspizieren und genehmigen

Bevor die generierte Richtlinie erstellt, angehängt oder durchgesetzt wird, druckt das Tool die generierte Netzwerkrichtlinie zur Inspektion und Validierung aus. Sobald du zugestimmt hast, wendet das Tool diese Änderungen entsprechend deinen Eingabeparametern an.

Wenden Sie das generierte Terraform-Skript an

Wenn Sie spezifizieren --export, erstellt das Tool eine JSON-Darstellung der generierten Policy und eine entsprechende Terraform-Konfiguration.

Überprüfen Sie das generierte Terraform, bevor Sie es Ihrer Infrastruktur-als-Code-Konfiguration hinzufügen oder terraform apply ausführen. Die Terraform-Ausgabe ist als Ausgangspunkt für die Verwaltung der generierten Richtlinie mithilfe von Infrastructure as Code gedacht.

Überprüfen der Migration

Nachdem das Tool die Richtlinie erstellt und angehängt hat, bestätigen Sie, dass sie sich wie erwartet verhält, bevor Sie sich darauf verlassen:

1. In der Kontokonsole klicken Sie auf Arbeitsbereiche, wählen Sie den Arbeitsbereich aus und bestätigen, dass die generierte Richtlinie unter Netzwerkrichtlinie aufgeführt ist.
2. Wenn du die Richtlinie im Trockenlaufmodus erstellt hast, generiere typischen Arbeitsbereichsverkehr und prüfe dann die Ablehnungsprotokolle, um zu bestätigen, dass die konvertierten Regeln mit deinem beabsichtigten Zugriff übereinstimmen. Wenn die Regeln korrekt sind, schalten Sie die Richtlinie in den Erzwingungsmodus. Siehe Den Erzwingungsmodus festlegen.

Die Ablehnungsprotokolle werden in der system.access.inbound_network Tabelle im Unity-Katalog gespeichert. Ablehnungen im Probelauf werden in der Spalte access_type mit dem Wert DRY_RUN_DENIAL angezeigt, und erzwungene Ablehnungen werden als DROP angezeigt. Siehe "Denialprotokolle überprüfen".

Einschränkungen von Migrationstools

Das Migrationstool unterstützt die folgenden Konfigurationen nicht:

• Eine bestehende restriktive, kontextbasierte Ingress-Policy ist bereits dem Arbeitsbereich zugewiesen. Wenn das Tool so konfiguriert ist, dass es eine neue Richtlinie erstellt und zuweist, bricht es ab, wenn der Arbeitsbereich bereits eine zugewiesene Richtlinie mit erzwungenen oder Probelauf-Eingangsregeln hat. Eine Alles-zulassen-Baseline-Richtlinie löst diese Prüfung nicht aus.

Nächste Schritte