Job Template Permissions

Project Discussions
,
1

I would like discuss this issue:

Current Job Template (JT) Permissions

To edit certain fields (like name/description/forks), you just needed admin_role to the JT.

To edit other “sensitive” scalar fields (like allow_simultaneous/job_type/ask_forks_on_launch), you need both admin_role to the JT and use_role to a collection of associated resources - which are project and inventory… also read_role to execution environment.

To edit direct relational fields, which are project, inventory, and execution environment, you need

  • admin_role to the JT
  • relevant role to the new item, like use_role for project
  • all the permissions already mentioned about “sensitive” fields, which means needing permission to all existing direct relational fields - so current project, inventory, and execution environment

Most Reasonable Permissions

Here’s a branch that I think shows what I think is most sensible:

This argues that permission to edit a JT should be:

  • admin_role to the JT, and this is all if it is a scalar field
  • relevant role to any new field being attached, like use_role to a project

Thoughts

Current permissions are poorly documented (if at all), and if the user got a permission error due to one of the corner cases we have coded for, it wouldn’t be a coherent denial of permission, but just a source of frustration. The “sensitive” field list has not been maintained over time so it includes much more than it should, even if it is a good idea.

However, I think we should take serious at least a little bit of the idea of what I would call inventory protection, because I think that’s the only reasonable idea from current permission rules. If someone has admin_role to a JT, they should be able to change anything they wish if they don’t have use_role to the inventory. For the most part, I think that should be limited to changing project/playbook/EE, because these dictate how the inventory is acted on.

I could be convinced otherwise on this idea of inventory protection. If we keep any vestige of that idea, there should be thought given to the user experience of someone receiving a permission error, and docs to support it.

2 Likes
2

@AlanCoding Is there any concern of sensitive data leaking if an user has admin_role to a JT but not use_role to the inventory with the proposed change?

I’m thinking of scenarios where someone is storing variable data in an inventory that is restricted for one reason or another. This also spawns a question in my mind as to how AWX combines inventory and secrets data with the JT (pardon my ignorance on the topic, I still have much to learn about the inner workings of AWX).

1 Like
3

Yeah, those concerns are exactly why these restrictions exist in the first place.

People do store secrets in inventory variable data, and with control of the playbook you can get this out. However, I think that would be a bigger concern for not having use_role to the credential, and using access to the project/playbook to get that data out. It’s probably not uncommon that someone has a general “debug any variable” lying around in their project…

So the ability to change the playbook can equate to the ability to go print all the variables.

3 Likes
4

Understood, thanks! :+1: