I’m trying to find documentation on how access to users for “juju actions” works.
I would like to provide actions to users with limited (read?) access to a model or even allow access to specific actions in charms based on users access.
I can’t find documentation on this in the following links that I use for reading up on users in juju…
Looking for help on the topic…
You need “write” access to a model to be able to run an action.
“admin” access is needed to use “juju run” (“juju exec” using the opt-in v2 syntax")
@wallyworld thanx!
I would love to see a more expressive access system for actions as this is very useful for handing out operations tasks without providing ssh access to nodes/services.
With write permissions, can you alter config for charms?
Yes, model write access gives the user the ability to set application config.
There’s currently only 3 levels of model access - read, write, admin.
It’s been recognised that a finer grained RBAC mechanism is desirable. But as yet that work is yet to make it to the top of the priority list. We’re coming to the end of a development cycle so we can consider it again for next cycle.
The ability to hand out right to run “actions” via write was quite useful and I think that would be good to add to the official documentation for actions themselves.
To be able to hand out “action” rights to individuals with no possibility to “ssh” into nodes are extremely valuable since it allows us to decouple operators from admins. Effectively providing an extra layer of security, while still being able to operate the services deployed by juju.
Yes, RBAC on specific actions, and RBAC on SSH, both make sense.
I think the granularity of those permissions is interesting too. There are actions which are believed to be non-destructive, and there are actions which are known to be destructive, and there are actions which might be a bad idea if run at the wrong time.
In a sense, there is a community perspective on that; the charm publisher could group actions into sets which have reason to be treated the same way from an RBAC perspective. This would require an extension to charm metadata, perhaps in the form of tags on actions defined there so they could be in multiple groups.
Separately, organisations may have a policy which diverges from that bottom-up approach, and have their own sets of actions they wish to grant permissions to for particular users.
Erik, it would be welcome for you to develop a spec which addresses both of these.
First, the metadata in the charm which provides the ‘standard’ view of sets of actions. Perhaps also a basic initial set of recommended tags for consistency across charms, such as ‘destructive’, ‘dangerous’, ‘performance-impact’, ‘safe’, etc. Having a common set of tags would make it easier for people setting up their own policies.
And second, the commands and outputs which would enable custom action groups for a particular deployment, and the RBAC for those. In other words, if I want to deploy something and specify that a particular set of actions can be called by a particular set of users, making up my own subset of actions by effectively creating a new tag on the actions and referencing that, what would the commands look like, and what would the show-permissions or similar output look like?
With a spec like that we would have a nice target for estimation and development, or for a contributor to tackle.
SSH I would definitely handle completely separately, with the ability to specify who can SSH at all.
I think all of the above items are relevant and interesting ways of expanding on juju actions.
As we are using “jimm” today, users are slowly discovering the powerful ability to “share” models.
It looks like this when Adam and Erik are developing a charm for example or managing a service:
=== Conversation ====
[Adam] - Hey, Erik, I have a problem in my model, I cant figure it out - can you help me?
[Erik] - Sure, can you grant me access to the model?
[Adam] - Yeah, sec I’ll grant you admin.
juju grant ERIK@scania adams-model-99 admin
[Erik] - Thanx, I’ll look.
$ juju models
Controller: jimm.scania.com
Model Cloud/Region Type Status Machines Cores Access Last connection
ADAM@scania/adams-model-99 vsphere-cloud/sweden-region-1 vsphere available 3 0 admin never connected
eriks-model-1 maas-cloud/sweden-region-1 maas available 5 0 write never connected
[ Erik ] - Thanx Adam, I’ll help you.
juju switch ADAM@scania/adams-model-99
juju add-ssh-key "$(cat ~/.ssh/id_rsa.pub)"
juju ssh 0
...
...
...
exit
[Adam] - Thanx Erik, I’ll remove your access so you don’t have to see it any more!
juju revoke ERIK@scania admin adams-model-99
=======
The above scenario is a good example for admins of models, but introduce the security issue that Erik will be now allowed to SSH into the machine to perform arbitrary commands as root and could also at that point install whatever keys to bypass subsequent “juju revoke”. Erik will in effect be able to get full control over the node without Adam be able to prevent that.
This second scenario below, is what we are exploring now which is alot better for operators which should not be allowed access to our servers via SSH:
Adam : Is the admin of a Nextcloud cluster with access to ssh login etc.
David the Operator : Is a remote contractor which should have no access to the Nextcloud instance since it contains private or sensitive data which David should have no access to, e.g. no SSH access at all. David should however be able to help out with some predefined tasks (juju actions).
====== Conversation =======
[Adam] - Hey, David the Operator, can you register a ERIK as admin-user in our Nextcloud test instance?
[David the Operator] - Sure, which model?
[Adam] - Its in the juju model ADAM@scania/nextcloud-test
[David the Operator] - I’ll do it now. My operator username is DAVID@scania (attached to Candid + Active Directory)
[Adam] - Great, I’ll give you access to the model, please go ahead and make ERIK administrator with the register-admin action.
juju grant DAVID@scania nextcloud-test write
[David the Operator]
I’ll go ahead with that now.
juju switch ADAM@scania/nextcloud-test
juju run-action nextcloud-admin/0 register-admin username=ERIK
[David the Operator] The action went well, I’m all done.
[Adam] Thanx David, I’ll revoke your access to the model now. Thanx for your help.
juju revoke DAVID@scania read nextcloud-test
====
While this prevents David from installing any SSH-keys or logging in, the granularity of access to actions is too low.
What if there are actions that only “admins” should be allowed to run? “write” access gives access to ALL actions.
What if some units or subordinates have actions that should be exposed to David only?
I would love to be able to do something like:
juju grant DAVID@scania --unit nextcloud/0 action=register-admin
or addressing “general” access to actions.
juju grant everyone --unit nextcloud/0 actions
or …
juju grant everyone --application nextcloud actions
… something like the above.
Rather than granting permissions to specific actions, lets grant them to action-tags. Let’s also develop a community reference set of action-tags which we encourage all charms to define consistently, but which can be overridden in a particular deployment. If we do that tastefully, then most organisations will never need to define tags of their own, except for very specialised cases.
Interesting.
So, something like:
juju action-grant ERIK@external run action-tags="#service, #reboot, #inspect, #getsecrets
Would allow Erik to run actions with tags #xyz
Is this more in line of what you think?
In general, yes, that was where I was headed. Rather than grant permissions on the action itself (if there are many actions that is a pain, and if there is one you could just run the action yourself!) I was thinking to make it easier to grant high level permissions.
We use RBAC for permissions. So you really want ERIC@external to have a role, and then grant that role permission to do something.
My colleague Gustavo suggests we may actually just want to be opinionated about roles, and map actions to roles in the first place, to avoid the extra level of indirection. Worth discussing.
So let’s say actions are by default assigned to “admin” which would make them work by default.
Then subsequent added users (juju grant) would be added automatically to a group with low permissions (name like, guests) which could then be used with tags.
juju action-grant groupname=guests action-tags="#inspect"
… and for more general delegation to all actions.
juju action-grant groupname=operators action-tags="#all"
Makes me think that a set of ‘built in’ tags will perhaps be needed…
Is there some other way to think about this to get a reference point? I really would like the action system to be kept simple to understand since it’s a really good feature that is also very easy to implement today with juju. Don’t want it to be messed up by adding elements that are non intuitive or complex.
In a sense, the current system is great from that perspective. But yeah… Too rudimentary.
Another aspect to consider is how the
juju run
command intersect here, if it is.