we have automated some infrastructure configuration by the means of an Ansible playbook (and a custom module).
Our goal would be, to allow regular users in an organization to re-use the playbook / the job template defined on the organization level (this we already achieved) but connect their own inventories, especially with their own sets of group vars, …
From the existing roles and possible role assignment, I could not find a way, how to achieve this. Especially allowing users to connect their inventory in a git repository.
Ideally a user should be allowed to either create an inventory and directly connect it to the git repository, or additionally allow him to create a project, connect that, and use the “source from project” in the inventory to connect .
is there some means to customize the roles, add own roles, something like “project creator” or “inventory creator”?
and/or
is there an alternative to “source from project” , that allows users to connect their inventory to a git repository ? In this case, the user still somehow would need to be enabled to create the inventory. Or an empty inventory is pre-allocated for that user, and he then can configure the sources. But the manual step would be suboptimal.
Not as of 24.2.0. There’s a new django based RBAC system that’s been introduced in >=24.3.0, but I don’t actually know the full implications of the change. IIRC, it will let you define custom permissions though, so you might be able to fine-tune permissions like you’re wanting.
If the new RBAC doesn’t meet your needs, or if you’re not comfortable using the latest tagged release yet, then yes you will have to manually pre-configure projects and inventories for your regular users. You can assign admin rights to those users/teams for those specific projects/inventories after the fact, or it can just be setup by you and automatically updates whenever your users run dependent jobs.
Personally, I think it would make sense to keep “sources of truth” in one inventory to merge data sources prevent host duplication; then use “Smart” or “Constructed” inventories to restrict what your users actually have access to.
Thanks a lot for your answer @Denney-tech
I will have a look onto awx > 24.3.0
Regarding “sources of truth” in one inventory, this most probably will not work for what we are doing:
We have automated the creation of firewall rules via REST API via Ansible role/playbook.
The rules for one application are described in the group vars of one inventory.
The granularity then is one inventory per application team to maintain the rules for that application.
In each of those inventories there in fact even only is one host, the endpoint host for the REST API.
There might be application teams who are doing more automation via Ansible and provide their own playbooks and more hosts in their inventories, but many of those applications already have some installation automation and they only need the firewall rule automation in addition.
Does this make sense ?
I see the conundrum. Having the same rest api endpoint as a unique inventory host per project would make sure that your various teams/application projects don’t re-use the same vars and cause problems/conflicts between them. In my case, I as a System Admin maintain the inventory of our hosts, but dev/application admins have their own “inventory” that contains only group_vars or host_vars. Their inventory doesn’t have any hosts, and their vars get merged into constructed inventories in AWX (how I assign hosts to the application’s groups). Since I don’t have multiple application/dev teams using the same set of hosts, this works well for me, but this probably wouldn’t work very well in your case.
So, in the meantime, you’ll need to pre-create projects/inventories and give admin access to the respective teams/users. You might be interested in using infra.controller_configuration to define the projects/inventory as code. I’m in the process of adopting the collection myself for deploying the majority of AWX as code.
Only tips regarding infra.controller_configuration I have so far, use the filetree_create role to export the current state of your AWX instance to help with getting started. Then use the filetree_read and/or dispatch roles to configure AWX with your filetree vars directory (haven’t actually gotten this far yet, I’m building a role to template the filetree since I have both prod/non-prod environments and I want them to be mostly identical).