Hantera identiteter, behörigheter och tillgångar för pipelines

Identiteter, behörigheter och privilegier styr vem som kan köra, hantera och söka i pipelines och den data som de genererar.

Databricks rekommenderar att du använder Unity Catalog för alla nya pipelines. Som standard kan materialiserade vyer och strömmande tabeller som skapats av pipelines som konfigurerats med Unity Catalog endast frågas av pipelineägaren. Se Använd Unity Catalog med pipelines.

Om dina pipelines publicerar datamängder till äldre Hive-metaarkiv kan du läsa Använda Lakeflow-pipelines med äldre Hive-metaarkiv.

Allmänna metodtips för identitetskonfigurationer finns i Metodtips för identiteter.

Vilken identitet används för pipelineuppdateringar?

Pipelines bearbetar uppdateringar med identiteten för run-as-användaren. Som standard är användaren som kör pipeline-skaparen, men du kan ändra den till en annan användare eller ett tjänsthuvudnamn. Se Ange användare att köra som.

Databricks rekommenderar att du ställer in Run as-användaren på ett tjänstens huvudnamn, så att uppdateringar av pipelines inte knyts till en enskild användares konto. Se Tjänstens huvudprincipaler.

Ge det tjänsthuvudnamnet endast de Unity Catalog-behörigheter som pipelinen behöver, i stället för omfattande åtkomst på kontonivå. Till exempel, bevilja USE CATALOG på målkatalogen, USE SCHEMA och lämpligt CREATE-privilegium (CREATE MATERIALIZED VIEW eller CREATE TABLE) på utdataschemat, och SELECT på dess källor. För den fullständiga uppsättningen av privilegier som krävs för att publicera till Unity Catalog, se Krav.

Vem kan köra en uppdatering av en pipeline?

Pipelineuppdateringar kan köras av alla användare eller tjänstehuvudnamn med behörigheterna CAN RUN, CAN MANAGE eller IS OWNER.

Vem kan visa en pipeline och dess utdata?

Om du vill öppna en pipeline och visa dess information behöver en användare minst behörigheten CAN VIEW för pipelinen. En fullständig lista över pipelinebehörighetsnivåer och de funktioner som var och en ger finns i ACL:er för Lakeflow-pipelines.

Om du vill visa pipelinen som ligger bakom en streamingtabell eller materialiserad vy måste en användare som inte är administratör också ha behörigheten REFRESH på den streamingtabellen eller materialiserade vyn, utöver sina behörigheter på pipelinen. Utan behörigheten REFRESH visar pipeline-URL:en att Pipelinen inte är tillgänglig.

Konfigurera pipelinebehörigheter

Du måste ha behörigheten CAN MANAGE eller IS OWNER på pipelinen för att hantera behörigheter. Pipelines använder åtkomstkontrollistor (ACL: er) för att kontrollera behörigheter. En fullständig lista över behörigheter och deras funktioner finns i ACL:er för Lakeflow-pipelines.

  1. I sidofältet klickar du på Jobb och pipelines.
  2. Välj Namnet på en pipeline.
  3. Klicka på Dela. Dialogrutan Behörighetsinställningar visas.
  4. Klicka på Välj användare, Grupp eller Tjänstens huvudnamn... och välj en användare, grupp eller tjänstens huvudnamn.
  5. Välj en behörighet från den nedrullningsbara menyn för behörighet.
  6. Klicka på Lägg till.
  7. Klicka på Spara.

Ändra pipelineägaren

Som standard är pipelineägaren också den användare som pipelineuppdateringar körs som. Om ägaren ändras ändras den identitet som används för framtida uppdateringar.

Om du vill ändra den identitet som används när pipelineuppdateringar körs, utan att ändra ägaren, anger du i stället ”kör som”-användaren. Se Ange användare att köra som.

Om du vill ändra en pipelines ägare måste du vara både metaarkivadministratör och arbetsyteadministratör. Ändra ägaren med hjälp av användargränssnittet eller REST-API:et.

Använda användargränssnittet

  1. I sidofältet klickar du på Jobb och pipelines.
  2. Välj pipelinens namn .
  3. Klicka på Dela. Dialogrutan Behörighetsinställningar visas.
  4. Rensa den aktuella ägaren och välj sedan den nya ägaren. Ägaren kan vara en användare eller ett huvudnamn för tjänsten. Databricks rekommenderar ett huvudnamn för tjänsten. Se Tjänstens huvudprincipaler.
  5. Klicka på Spara.

Använda REST-API:et

Om ägarkontrollen inte är tillgänglig i användargränssnittet, till exempel för vissa internt hanterade pipelines, ändrar du ägaren med REST API-åtgärden Ange pipelinebehörigheter . Ange den nya ägarens (eller user_name för tjänstens service_principal_name huvudnamn) med IS_OWNER behörighetsnivån:

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

Om ingen användare är både metastore-administratör och arbetsyteadministratör

Om ingen i din organisation är både metaarkivadministratör och arbetsyteadministratör kontaktar du din Databricks-representant för att ändra pipelineägaren.

Tillåt icke-administratörsanvändare att visa drivrutinsloggarna från en Unity Catalog-aktiverad pipeline

Som standard kan endast pipelineägaren och arbetsyteadministratörerna visa drivrutinsloggarna från klustret som kör en Unity Catalog-aktiverad pipeline. Du kan aktivera åtkomst till drivrutinsloggarna för alla användare med behörigheten CAN MANAGE, CAN VIEW eller CAN RUN genom att lägga till följande Spark-konfigurationsparameter i configuration objektet i pipelineinställningarna:

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

Referensuppgifter från ett hemligt omfång

Hårdkoda aldrig API-nycklar, databaslösenord eller tokens i din pipeline-källkod. Lagra dem i ett hemligt område och referera till dem under körning:

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

Azure Databricks redigerar automatiskt hemliga värden ([REDACTED]) där de annars skulle skrivas ut till en anteckningsbok eller loggutdata, och du kan begränsa vem som kan läsa ett scope med en hemlig ACL. Se Hemlig hantering.

Skydda känslig data i pipeline-utgången

För kolumner som innehåller personligt identifierbar information (PII), tillämpa Unity Catalog-styrning på de tabeller som din pipeline producerar istället för att skriva anpassad maskeringslogik i din pipelinekod:

  • Kolumnmasker maskerar eller hashar värdet i en kolumn beroende på vilken grupp den frågande användaren tillhör.
  • Radfilter begränsar vilka rader en användare kan se.

Genom att tillämpa dessa kontroller på tabellen i Unity Catalog skyddas personligt identifierande information konsekvent för alla som använder tabellen, inklusive dashbord, ad hoc-frågor och efterföljande jobb, inte bara i pipelinen. Se Radfilter och kolumnmasker. Som ett ytterligare steg, håll PII isolerad till specifika kolumner eller tabeller i ett tydligt namngivet schema så att åtkomstbeviljanden och revisioner blir enklare att resonera kring.

  • Last updated on