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.
@alesstimec