azure-dbx-secret-scope-read

id: azure-dbx-secret-scope-read
emits: CanReadSecret
description: READ ACL on a Databricks secret scope allows reading its secrets via dbutils.secrets.get().
match_effective_permission:
  action: databricks:secrets:read
  scope_type: secret_scope
where:
- principal has READ ACL on the target secret scope (GET /api/2.0/secrets/get?scope=<scope>&key=<key>)
- if secret_scope.backend_type == AZURE_KEYVAULT then principal (or the cluster MI) must have Key Vault
  secret/get permission
emit:
  source_type: Identity
  target: <Databricks Secret Scope (Secret)>
  permissions:
  - "databricks:secrets:read (READ ACL on scope \u2014 GET /api/2.0/secrets/get)"
  conditions: []
  state_logic: ACTIVE for Databricks-managed secret scopes. CONDITIONAL(key_permission) for Key Vault-backed
    scopes unless the Access Connector MI's Key Vault permissions are confirmed (the MI must have secrets/get
    on the vault).
  false_positive_note: "The Databricks API obfuscates secret values in notebook output (replaces with\
    \ [REDACTED]) but dbutils.secrets.get() returns the plaintext string to in-memory code. The READ ACL\
    \ IS a credential-access primitive \u2014 code on the cluster can exfiltrate the value. KV-backed\
    \ scopes proxy to Key Vault via the Access Connector MI; the MI must have Key Vault secret get permission\
    \ \u2014 without it, the read returns an error. Honor that gate: emit CONDITIONAL(key_permission)\
    \ for KV-backed scopes unless the MI's Key Vault access is confirmed."
  narrative: '{principal.name} has READ ACL on Databricks secret scope {target.name}; any code it runs
    on the cluster can read secret values via dbutils.secrets.get(), accessing stored credentials (storage
    keys, connection strings, API keys).'