Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
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.