Support IS_OWNER as a top-level permission #1387
Conversation
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #1387 +/- ##
==========================================
+ Coverage 52.25% 53.63% +1.37%
==========================================
Files 317 351 +34
Lines 18004 20290 +2286
==========================================
+ Hits 9408 10882 +1474
- Misses 7903 8610 +707
- Partials 693 798 +105 ☔ View full report in Codecov by Sentry. |
| return diag.Errorf("'run_as' must be set for all jobs when using 'mode: production'") | ||
| // We need to verify that there is only a single deployment of the current target. | ||
| // A good way to enforce this is to explicitly set root_path or run_as. | ||
| if !isExplicitRootSet(b) && !isRunAsSet(r) { |
There was a problem hiding this comment.
We used to require
run_as: [email protected]
but when considering collaborative deployment, we prefer
root_path: /Users/Alice
This change makes it so either restriction is allowed for mode: production.
There was a problem hiding this comment.
Can we also warn if only run_as is set? It doesn't prevent multiple deployments.
| // Only show a warning in case a principal was used for backward compatibility | ||
| // with projects from before the DABs GA. | ||
| if isPrincipalUsed { | ||
| return diag.Warningf("target with 'mode: production' should specify explicit 'workspace.root_path' to make sure only one copy is deployed") |
There was a problem hiding this comment.
Service principals still have an exception, like they used to.
| var levelsMap = map[string](map[string]string){ | ||
| "jobs": { | ||
| IS_OWNER: "IS_OWNER", |
There was a problem hiding this comment.
Only a few resources, like jobs, actually have an "owner": https://docs.databricks.com/en/security/auth-authz/access-control/index.html. For almost all the others we don't distinguish between the owner and the other can-manage users.
Note that clusters is a special case here. They don't have an owner permission but treat the creator as a kind of owner that has special privileges. There's even a special API for changing that notion of "owner": https://docs.databricks.com/api/workspace/clusters/changeowner. Once we do clusters we should discuss if we want this notion of an owner to affect how clusters are created, or if we perhaps want to show a warning when someone who doesn't have IS_OWNER would be the first creator of a cluster.
lennartkats-db
changed the title
|
@pietern could you take another look? |
| return diag.Errorf("'run_as' must be set for all jobs when using 'mode: production'") | ||
| // We need to verify that there is only a single deployment of the current target. | ||
| // A good way to enforce this is to explicitly set root_path or run_as. | ||
| if !isExplicitRootSet(b) && !isRunAsSet(r) { |
There was a problem hiding this comment.
Can we also warn if only run_as is set? It doesn't prevent multiple deployments.
| // Clear targets after loading. | ||
| b.Config.Targets = nil | ||
| b.Config.Environments = nil | ||
|
|
There was a problem hiding this comment.
This makes them part of the validation output.
Production mode is only validated if the production target is selected, so you can access b.Workspace.RootPath directly instead of going into the targets map.
| func ApplyWorkspaceRootPermissions() bundle.Mutator { | ||
| return &workspaceRootPermissions{} | ||
| func ApplyFolderPermissions() bundle.Mutator { | ||
| return &applyFolderPermissions{} | ||
| } |
There was a problem hiding this comment.
Why the rename? The mutator still applies only to the workspace root path.
| @@ -87,6 +87,7 @@ func validateRunAs(b *bundle.Bundle) error { | |||
| } | |||
|
|
|||
| // DLT pipelines do not support run_as in the API. | |||
| // TODO: maybe oly make this check only fail when owner != runas | |||
There was a problem hiding this comment.
This is addressed in the other PR and can be removed.
| } | ||
|
|
||
| // Only apply the owner from top-level permissions if the local resource | ||
| // didn't have an owner. |
There was a problem hiding this comment.
Which variable contains the top level permissions and which one the resource permissions?
There was a problem hiding this comment.
The comment seems to be the reverse of what is actually happening: it extends the permissions with the non-owner permissions from the top-level and retains the resource-specific owner.
|
@andrewnester Could you take a look as well? |
Changes
This adds a top-level IS_OWNER permission to help with collaborative deployment scenarios:
mode: productionnow accepts a top-level owner as an alternative to a run_as identity.Tests
Unit tests, manual experimentation.