azure-dbx-secret-scope-manage

id: azure-dbx-secret-scope-manage
emits: CanGrantPermission
description: MANAGE ACL on a Databricks secret scope allows granting READ/WRITE/MANAGE access to other
  principals and managing ACLs.
match_effective_permission:
  action: databricks:secrets:manage
  scope_type: secret_scope
where:
- principal has MANAGE ACL on the target secret scope (PUT /api/2.0/secrets/acls)
emit:
  source_type: Identity
  target_type: Identity
  source: <principal>
  target: <any Identity>
  permissions:
  - "databricks:secrets:manage (MANAGE ACL on secret scope \u2014 PUT /api/2.0/secrets/acls)"
  false_positive_note: "MANAGE on a scope allows granting READ/WRITE/MANAGE to any user (ACL modification).\
    \ MANAGE also allows the holder to DELETE secrets, but it does NOT automatically grant WRITE (PUT\
    \ new secrets); the holder must have READ and WRITE ACLs separately to read and write secrets. Databricks\
    \ secret scope ACL model has distinct READ, WRITE, and MANAGE levels where MANAGE does NOT imply WRITE.\
    \ A Databricks workspace admin can manage ACLs on all scopes regardless of scope-level ACLs. Emit\
    \ CanGrantPermission targeting any Identity (the scope of the grant is bounded to the secret scope's\
    \ contents). Do NOT conflate with CanReadSecret \u2014 MANAGE alone does not read secrets; that requires\
    \ READ ACL."
  narrative: '{principal.name} has MANAGE ACL on secret scope {target.name} (PUT /api/2.0/secrets/acls)
    and can grant READ/WRITE/MANAGE access to any workspace user, including itself.'