Condividi tramite


Concedere autorizzazioni tramite programmazione

Importante

La scalabilità automatica di Lakebase è disponibile nelle aree seguenti: eastus, eastus2, centralus, southcentralus, westus, westus2, canadacentral, brazilsouth, northeurope, uksouth, westeurope, australiaeast, centralindia, southeastasia.

La scalabilità automatica di Lakebase è la versione più recente di Lakebase, con calcolo autoscalabile, scalabilità fino a zero, ramificazione e ripristino immediato. Se sei un utente provisioning di Lakebase, vedere Lakebase provisioning.

Le autorizzazioni del progetto Lakebase possono essere gestite a livello di codice usando l'API di autorizzazioni standard di Azure Databricks, l'interfaccia della riga di comando di Azure Databricks, gli SDK di Azure Databricks e Terraform.

Per una panoramica dei tipi di autorizzazione, delle autorizzazioni predefinite e di come gestire le autorizzazioni nell'interfaccia utente di Lakebase, vedere Gestire le autorizzazioni del progetto.

Livelli di autorizzazione

I livelli di autorizzazione concedibili per i progetti Lakebase sono CAN_USE e CAN_MANAGE. CAN_CREATE è un livello ereditato che passa automaticamente dall'area di lavoro a tutti gli utenti e non può essere concesso o revocato in modo esplicito in un progetto. I tentativi di concedere CAN_CREATE tramite l'API restituiscono HTTP 400.

Gli ID progetto sono UUID (ad esempio, a446ad92-e936-454b-a31c-a0742e53dd5c). Recupera i dati con databricks postgres list-projects ed esamina il campo uid.

REST API

Le autorizzazioni del progetto usano l'API autorizzazioni standard di Azure Databricks all'indirizzo /api/2.0/permissions/database-projects/{project_id}.

Ottenere le autorizzazioni correnti

curl -X GET "https://${DATABRICKS_HOST}/api/2.0/permissions/database-projects/${PROJECT_ID}" \
  -H "Authorization: Bearer ${DATABRICKS_TOKEN}" | jq

Concedere o aggiornare le autorizzazioni (PATCH)

curl -X PATCH "https://${DATABRICKS_HOST}/api/2.0/permissions/database-projects/${PROJECT_ID}" \
  -H "Authorization: Bearer ${DATABRICKS_TOKEN}" \
  -H "Content-Type: application/json" \
  -d '{
    "access_control_list": [
      {
        "user_name": "user@example.com",
        "permission_level": "CAN_USE"
      }
    ]
  }'

Per concedere le autorizzazioni a un gruppo o a un'entità servizio, sostituire user_name con group_name o service_principal_name.

Annotazioni

PATCH è additivo e non può ridurre il livello di un'autorizzazione più elevata esistente. Ad esempio, l'applicazione di una patch CAN_USE a un utente che possiede già CAN_MANAGE non ha alcun effetto. Per effettuare il downgrade o rimuovere un'autorizzazione, usare invece PUT.

Sostituire tutte le autorizzazioni esplicite (PUT)

Avviso

PUT sostituisce l'intero ACL esplicito. Qualsiasi utente, gruppo o entità servizio non incluso nel corpo della richiesta perde l'autorizzazione concessa in modo esplicito. Le autorizzazioni ereditate, ad esempio gli amministratori dell'area di lavoro, non sono interessate.

curl -X PUT "https://${DATABRICKS_HOST}/api/2.0/permissions/database-projects/${PROJECT_ID}" \
  -H "Authorization: Bearer ${DATABRICKS_TOKEN}" \
  -H "Content-Type: application/json" \
  -d '{
    "access_control_list": [
      {
        "user_name": "user@example.com",
        "permission_level": "CAN_MANAGE"
      }
    ]
  }'

Per informazioni di riferimento complete sull'API delle autorizzazioni, vedere API delle autorizzazioni.

CLI

Usare i comandi databricks permissions (che avvolgono l'API Autorizzazioni) per gestire le autorizzazioni di progetto dalla riga di comando.

Concedere o aggiornare le autorizzazioni

# PROJECT_ID is a UUID. Retrieve it with: databricks postgres list-projects
databricks permissions update database-projects ${PROJECT_ID} \
  --json '{
    "access_control_list": [
      {
        "user_name": "user@example.com",
        "permission_level": "CAN_USE"
      }
    ]
  }'

Ottenere le autorizzazioni correnti

databricks permissions get database-projects ${PROJECT_ID}

Annotazioni

Usare databricks permissions (non databricks postgres) per la gestione dell'ACL di progetto. Il databricks postgres sottocomando gestisce le risorse del progetto (rami, calcoli e così via), non le autorizzazioni.

SDK

Usare l'interfaccia WorkspaceClient.permissions in Python, Java o Go SDK per gestire le autorizzazioni del progetto.

PYTHON SDK

from databricks.sdk import WorkspaceClient
from databricks.sdk.service.iam import AccessControlRequest, PermissionLevel

w = WorkspaceClient()

# Retrieve your project UUID from: databricks postgres list-projects
PROJECT_ID = "<project-uuid>"

# Grant CAN_USE to a user (PATCH is additive and cannot downgrade)
w.permissions.update(
    request_object_type="database-projects",
    request_object_id=PROJECT_ID,
    access_control_list=[
        AccessControlRequest(
            user_name="user@example.com",
            permission_level=PermissionLevel.CAN_USE,
        )
    ],
)

# Get current permissions
permissions = w.permissions.get(
    request_object_type="database-projects",
    request_object_id=PROJECT_ID,
)
print(permissions)

# Revoke or downgrade: use set() (PUT), not update() (PATCH)
# update() with an empty list is a no-op; set() replaces the full explicit ACL
w.permissions.set(
    request_object_type="database-projects",
    request_object_id=PROJECT_ID,
    access_control_list=[
        # Include every identity that should retain explicit access
        AccessControlRequest(
            user_name="owner@example.com",
            permission_level=PermissionLevel.CAN_MANAGE,
        )
    ],
)

Java SDK

import com.databricks.sdk.WorkspaceClient;
import com.databricks.sdk.service.iam.*;

WorkspaceClient w = new WorkspaceClient();

// Retrieve your project UUID from: databricks postgres list-projects
String projectId = "<project-uuid>";

// Grant CAN_USE to a user (PATCH is additive and cannot downgrade)
w.permissions().update(new UpdatePermissions()
    .setRequestObjectType("database-projects")
    .setRequestObjectId(projectId)
    .setAccessControlList(List.of(
        new AccessControlRequest()
            .setUserName("user@example.com")
            .setPermissionLevel(PermissionLevel.CAN_USE)
    ))
);

// Get current permissions
ObjectPermissions permissions = w.permissions().get(
    new GetPermissionRequest()
        .setRequestObjectType("database-projects")
        .setRequestObjectId(projectId)
);

SDK di sviluppo Go

import (
    "github.com/databricks/databricks-sdk-go"
    "github.com/databricks/databricks-sdk-go/service/iam"
)

w, _ := databricks.NewWorkspaceClient()

// Retrieve your project UUID from: databricks postgres list-projects
projectID := "<project-uuid>"

// Grant CAN_USE to a user (Update is additive and cannot downgrade)
_, err := w.Permissions.Update(ctx, iam.UpdatePermissions{
    RequestObjectType: "database-projects",
    RequestObjectId:   projectID,
    AccessControlList: []iam.AccessControlRequest{
        {
            UserName:        "user@example.com",
            PermissionLevel: iam.PermissionLevelCanUse,
        },
    },
})

// Get current permissions
permissions, err := w.Permissions.Get(ctx, iam.GetPermissionRequest{
    RequestObjectType: "database-projects",
    RequestObjectId:   projectID,
})

Terraform

Usare la risorsa databricks_permissions con l'attributo database_project_name per gestire le autorizzazioni del progetto come Infrastructure as Code. Per un flusso di lavoro Terraform completo, tra cui creazione di progetti, esempi di gruppo e comportamento dichiarativo, vedere Gestire le autorizzazioni del progetto con Terraform.

resource "databricks_permissions" "project_perms" {
  database_project_name = databricks_postgres_project.app.project_id

  access_control {
    user_name        = "someone@example.com"
    permission_level = "CAN_USE"
  }
}

Per informazioni di riferimento complete sulle risorse, vedere databricks_permissions nel Registro Terraform.

Passaggi successivi