Zarządzanie tożsamościami, zezwoleniami i przywilejami dla potoków

Tożsamości, uprawnienia i przywileje określają, kto może uruchamiać potoki, zarządzać nimi oraz wysyłać zapytania do nich i do danych, które tworzą.

Databricks zaleca używanie Unity Catalog dla wszystkich nowych pipeline'ów. Domyślnie zmaterializowane widoki i tabele przesyłania strumieniowego tworzone przez potoki skonfigurowane za pomocą Unity Catalog mogą być zapytane tylko przez właściciela potoku. Zobacz Używanie Unity Catalogu z potokami.

Jeśli Twoje potoki publikują zestawy danych do starszego magazynu metadanych Hive, zobacz Używanie potoków Lakeflow ze starszym magazynem metadanych Hive.

Aby uzyskać ogólne najlepsze rozwiązania dotyczące konfiguracji tożsamości, zobacz Najlepsze rozwiązania dotyczące tożsamości.

Z jakiej tożsamości korzysta się przy aktualizacjach potoku?

Potoki przetwarzają aktualizacje z użyciem tożsamości użytkownika run-as. Domyślnie użytkownikiem, na którego uruchamiany jest potok, jest twórca potoku, ale można go zmienić na innego użytkownika lub nazwę główną usługi. Zobacz Ustawianie użytkownika Uruchom jako.

Databricks zaleca ustawienie wartości „Uruchom jako” na nazwę główną usługi, aby aktualizacje potoku nie były powiązane z kontem konkretnego użytkownika. Zobacz Zasady usługi.

Nadaj temu podmiotowi usługi tylko te uprawnienia Unity Catalog, których potrzebuje pipeline, zamiast szerokich uprawnień na poziomie konta. Na przykład przyznaj USE CATALOG w katalogu docelowym, USE SCHEMA oraz odpowiednie uprawnienie CREATE (CREATE MATERIALIZED VIEW lub CREATE TABLE) w schemacie wyjściowym, a także SELECT w jego źródłach. Pełny zestaw uprawnień wymaganych do publikacji w Unity Catalog można znaleźć w sekcji Wymagania.

Kto może uruchomić aktualizację potoku?

Aktualizacje potoku mogą być uruchamiane przez dowolnego użytkownika lub jednostkę usługi z uprawnieniami CAN RUN, CAN MANAGE lub IS OWNER.

Kto może zobaczyć potok i jego wyniki?

Aby otworzyć potok i wyświetlić jego szczegóły, użytkownik musi mieć co najmniej uprawnienie CAN VIEW do potoku. Aby zobaczyć pełną listę poziomów uprawnień potoków oraz uprawnienia, jakie zapewnia każdy z nich, zobacz Listy ACL dla potoków Lakeflow.

Aby wyświetlić potok obsługujący tabelę strumieniową lub widok zmaterializowany, użytkownik niebędący administratorem musi również mieć uprawnienie REFRESH do tej tabeli strumieniowej lub tego widoku zmaterializowanego, oprócz uprawnień do potoku. Bez uprawnienia REFRESH adres URL potoku wyświetla komunikat Potok jest niedostępny.

Konfigurowanie uprawnień potoku

Aby zarządzać uprawnieniami, musisz mieć uprawnienia CAN MANAGE lub IS OWNER na potoku. Rurociągi używają list kontroli dostępu (ACL) do kontrolowania uprawnień. Aby uzyskać pełną listę uprawnień i ich możliwości, zobacz Listy ACL potoków usługi Lakeflow.

  1. Na pasku bocznym kliknij pozycję Zadania i przepływy pracy.
  2. Wybierz nazwę potoku.
  3. Kliknij pozycję Share (Udostępnij). Zostanie wyświetlone okno dialogowe Ustawienia uprawnień .
  4. Kliknij pozycję Wybierz użytkownika, grupę lub jednostkę usługi... i wybierz użytkownika, grupę lub jednostkę usługi.
  5. Wybierz uprawnienie z listy rozwijanej uprawnień.
  6. Kliknij przycisk Dodaj.
  7. Kliknij przycisk Zapisz.

Zmienianie właściciela potoku

Domyślnie właściciel potoku jest również użytkownikiem, w imieniu którego są uruchamiane aktualizacje potoku. Zmiana właściciela zmienia tożsamość używaną do przyszłych aktualizacji.

Jeśli chcesz zmienić tożsamość, w ramach której uruchamiane są aktualizacje pipeline’u, bez zmiany właściciela, zamiast tego ustaw użytkownika „Uruchom jako”. Zobacz Ustawianie użytkownika Uruchom jako.

Aby zmienić właściciela potoku, musisz być zarówno administratorem magazynu metadanych, jak i administratorem obszaru roboczego. Zmień właściciela przy użyciu interfejsu użytkownika lub interfejsu API REST.

Korzystanie z interfejsu użytkownika

  1. Na pasku bocznym kliknij pozycję Zadania i przepływy pracy.
  2. Wybierz Nazwa potoku.
  3. Kliknij pozycję Share (Udostępnij). Zostanie wyświetlone okno dialogowe Ustawienia uprawnień .
  4. Wyczyść bieżącego właściciela, a następnie wybierz nowego właściciela. Właścicielem może być użytkownik lub jednostka usługi. Usługa Databricks zaleca jednostkę usługi. Zobacz Zasady usługi.
  5. Kliknij przycisk Zapisz.

Korzystanie z interfejsu API REST

Jeśli kontrolka właściciela jest niedostępna w interfejsie użytkownika, na przykład w przypadku niektórych potoków zarządzanych wewnętrznie, zmień właściciela za pomocą operacji interfejsu API REST Ustaw uprawnienia potoku. Określ nowego właściciela user_name (lub service_principal_name dla jednostki usługi) z poziomem uprawnień IS_OWNER:

{
  "access_control_list": [
    {
      "user_name": "new.owner@example.com",
      "permission_level": "IS_OWNER"
    }
  ]
}

Jeśli żaden użytkownik nie jest zarówno administratorem magazynu metadanych, jak i administratorem obszaru roboczego

Jeśli nikt w Twojej organizacji nie jest jednocześnie administratorem magazynu metadanych i administratorem obszaru roboczego, skontaktuj się z przedstawicielem Databricks, aby zmienić właściciela potoku.

Zezwalaj nie-administratorom na wyświetlanie dzienników sterownika z potoku z włączonym katalogiem Unity

Domyślnie tylko właściciel potoku i administratorzy obszaru roboczego mogą wyświetlać logi sterownika z klastra, który uruchamia potok z włączoną obsługą katalogu Unity Catalog. Aby włączyć dostęp do logów sterowników dla dowolnego użytkownika z uprawnieniami CAN MANAGE, CAN VIEW lub CAN RUN, należy dodać następujący parametr konfiguracji Spark do obiektu configuration w ustawieniach potoku:

{
  "configuration": {
    "spark.databricks.acl.needAdminPermissionToViewLogs": "false"
  }
}

Odniesienie do danych uwierzytelniających z tajnego zakresu

Nigdy nie koduj na stałe kluczy API, haseł do baz danych ani tokenów w kodzie źródłowym swojego pipeline'u. Przechowywać je w tajnym zakresie i odwoływać się do nich podczas działania:

api_token = dbutils.secrets.get(scope="orders-pipeline-secrets", key="external_api_token")

Azure Databricks automatycznie redaguje wartości tajne ([REDACTED]) tam, gdzie normalnie byłyby wydrukowane na notatniku lub w logach, a także możesz ograniczyć, kto może odczytać zakres za pomocą tajnego ACL. Zobacz Zarządzanie tajemnicami.

Chroń wrażliwe dane w wyjściu potoku

W kolumnach zawierających dane osobowe (PII) zastosuj zarządzanie Unity Catalog do tabel generowanych przez Twój pipeline, zamiast pisać własną logikę maskowania w kodzie pipeline:

  • Maski kolumn ukrywają lub haszują wartość kolumny na podstawie przynależności użytkownika wykonującego zapytanie do grupy.
  • Filtry wierszowe ograniczają , które wiersze użytkownik może zobaczyć.

Zastosowanie tych mechanizmów kontroli do tabeli Unity Catalog zapewnia spójną ochronę danych osobowych dla każdego odbiorcy tej tabeli, w tym pulpitów nawigacyjnych, zapytań ad hoc i zadań podrzędnych, a nie tylko w samym potoku przetwarzania. Zobacz Filtry wierszy i maski kolumn. Jako kolejny krok przechowuj dane PII w wydzielonych kolumnach lub tabelach w schemacie o jednoznacznej nazwie, aby łatwiej było zarządzać uprawnieniami dostępu i prowadzić audyty.

  • Last updated on