An example of a bundle that creates and uses a secret scope#83
An example of a bundle that creates and uses a secret scope#83
Conversation
anton-107
requested review from
andrewnester,
denik,
juliacrawf-db,
pietern and
shreyas-goenka
Co-authored-by: Julia Crawford (Databricks) <julia.crawford@databricks.com>
Co-authored-by: Julia Crawford (Databricks) <julia.crawford@databricks.com>
Co-authored-by: Julia Crawford (Databricks) <julia.crawford@databricks.com>
| permissions: | ||
| - level: CAN_VIEW | ||
| group_name: users | ||
| - level: CAN_MANAGE |
There was a problem hiding this comment.
Admins should have these permissions by default. Is there a reason to explicitly specify them?
There was a problem hiding this comment.
admins do not have MANAGE permissions by default, only the user creating the scope does
There was a problem hiding this comment.
Is this only limited to read permissions?:
https://arc.net/l/quote/fotmmsku
There was a problem hiding this comment.
I'm referring to permissions that are listed by secret scopes ACL - the only initial permission a new secret scope is getting, is that its create can MANAGE it. For other permissions to show up there, they need to be explicitly declared in the permissions section
There was a problem hiding this comment.
Okay, but do admins have MANAGE permission by default on the scope anyways? The docs seem to imply so.
Note: This is not blocking, an additional permissions block can't really hurt customers. I was curious about the intention though.
There was a problem hiding this comment.
the API doc does not say so: https://docs.databricks.com/api/workspace/secrets/createscope
only the initial_manage_principal is getting the MANAGE permission, and when created with DABS, it is always the caller
| spark_python_task: | ||
| python_file: "src/example_spark_python_task.py" | ||
| parameters: | ||
| - --scope_name={{job.parameters.scope_name}} |
There was a problem hiding this comment.
We could simplify this.
| - --scope_name={{job.parameters.scope_name}} | |
| - --scope_name=${resources.secret_scopes.my_secret_scope.name} |
This way the secret scope name is directly interpolated and you don't have to pass that as a job parameter.
There was a problem hiding this comment.
I would prefer to keep it this way in the example since this seems to be more idiomatic with the jobs docs and it also documents this particular way (not quite straightforward) to achieve this result
Co-authored-by: shreyas-goenka <88374338+shreyas-goenka@users.noreply.github.com>
Co-authored-by: shreyas-goenka <88374338+shreyas-goenka@users.noreply.github.com>
Co-authored-by: shreyas-goenka <88374338+shreyas-goenka@users.noreply.github.com>
Co-authored-by: shreyas-goenka <88374338+shreyas-goenka@users.noreply.github.com>
3 participants
No description provided.