We are starting conversations around Juju’s permission model and in the upcoming community workshop we would like to hear your opinions.
In this workshop, we want to gather your use cases to make sure we’re able to cover as many of them as we can and create a solution that fits best.
As usual, the session is open for everyone and no prior experience is needed. Come meet the community!
Wednesday 12 apr. • 17:00–18:00 (CEST) Google Meet https://meet.google.com/wvo-vrhr-mzw
Hi,
As stated in the workshop announcement, we are thinking of what the future access control system for Juju and JAAS should be and would like get you input. Please share use-cases and opinions as replies to this post.
Think about a specific problem you faced with Juju’s permission model, describe it and, if possible, describe the workaround you used to solve it.
Your opinions are important to us as we want to make sure the solution we come up with fits the needs of you, our end-users.
Yesterday somebody asked about enabling ssh access for non-admin users. Makes me wonder: Right now we assign blanket permission levels via juju grant or juju grant-cloud and then we can fine-tune them negatively (add specific restrictions) via juju disable-command. How about we make it possible to fine-tune them positively (add specific permissions) via ?? (juju enable-command is already taken, though what it does currently is better described as reenabling a command that was previously disabled).
One use case we have is that we need to provide access to a specific action of a charm for a remote “operator”, while other actions are restricted.
E.g. be able to add-remove permission for users on specific actions.
Today, users get alot of power and access to all actions along with access to alter the deployment (adding/removing units etc.)
A user should NOT be able to alter the state of the model in any way just because it has access to an action, NOR, should the user be allowed “juju add-ssh-key” etc.
For example, I would like to be able to do something like this:
$ juju action-allow erik@external myapplication/myaction
$ juju run-action myapplication/0 myaction
Success!
$ juju action-deny erik@external myapplication/myaction
$ juju run-action myapplication/0 myaction
Permission denied!
Actions (actions.yaml) would then need to be include additional metadata to accommodate for meaningful defaults, such as:
myaction:
default-persmission: allow
Which would also be great for charmers to differentiate between sensitive vs insensitive actions.
I think @erik-lonroth has a very good use case here. Maybe roles could be used as well, to reduce the number of allow or denies that would need to be administered.
I was mentioning the possibility to be able to run juju ssh without being model admin. This would, as an example, allow an operator to troubleshoot a unit on machine level, without having the possibility to modify the model.