The first time someone outside my team asked for AWX access, I almost just gave them admin. We only had a handful of job templates back then, and it felt faster than figuring out the "right" way to do it. That worked fine right up until our job templates could stop IRIS on a production primary. At that point, "just give them admin" stopped being a shortcut and started being a problem waiting to happen.
AWX actually has a pretty solid permission system built in — you just have to dig past the default screens to find it. Here's how I think about it now, and how I've set it up so people can run what they need without being able to quietly change what a playbook does.
Three Things to Understand: Organizations, Teams, Users
Organizations are the big container everything else sits inside — inventories, job templates, credentials, all of it. If you're a small team, one organization is probably enough. Once you've got groups who genuinely shouldn't see each other's stuff — say, your infra team and your app deployment team — separate organizations is how you keep that clean.
Teams live inside an organization. A team is just a group of people with a name. By itself it doesn't grant anything — you still have to go and give that team access to specific things. The whole point of using teams instead of adding people one by one is that when someone joins or leaves, you just update their team, not every single job template they touch.
Users can be on more than one team, and you can also give a user permission directly without putting them on a team at all. I'd avoid doing that unless it's a genuine one-off. Direct permissions are the kind of thing that gets forgotten, and then a year later someone's doing an access review and can't figure out why a person still has access to something nobody remembers giving them.
The Roles You'll Actually Use
AWX comes with a handful of built-in roles. In practice, you'll mostly use these four:
Admin means full control — including the power to hand access to other people. Keep this one for a small group. It's not just "can run this," it's "can decide who else gets to."
Execute is what most people need. It lets someone launch a job template without letting them edit it. For our kernel patching and IRIS job templates, almost everyone is on Execute. They can run the patch, they can see the logs, but they can't change what the playbook actually stops or in what order.
Use is for things like credentials and inventories. It lets a job template use a credential to log in somewhere, without the person running the job ever seeing what that credential actually is. This is what makes CyberArk-backed credentials in AWX worth setting up properly.
Read is just visibility — you can look, you can't touch. Good for auditors, or for someone who needs to see what ran without being able to launch anything themselves.
How I've Actually Set This Up
Roughly, it looks like this:
A Patching team gets Execute on the patching job templates, and Use on the inventories and credentials they need. They can run the monthly cycle and see what happened. They can't touch the playbook that stops IRIS on DB01.
A Platform Admin team gets Admin on the job templates, projects, and credentials. This is the small group that actually edits playbooks, updates where the automation pulls from, and decides who else gets access.
A Read-only team is for anyone who just needs to confirm a patch run happened, without needing to trigger anything.
I also keep production IRIS automation in a separate organization from general server provisioning. Some people have access to both, but keeping them apart means a mistake in one place can't accidentally touch a credential or inventory that belongs somewhere else.
Where People Usually Trip Up
The most common one — handing out Admin because it "just works," instead of Execute. Execute occasionally gets in someone's way, like when they try to edit a survey field and can't, and then you have to explain why. But honestly, that bit of friction is doing its job. If someone needs to edit templates regularly, that's a sign they belong on the admin team, not a reason to give everyone admin so nobody has to ask.
Second one — giving permissions to individual people instead of teams, usually because it's quicker in the moment. It rarely gets cleaned up later. A few months on, you've got three people with random direct access that doesn't match any team, and nobody remembers why.
Third — not separating Use from Admin on credentials. If the people running a job can also edit the credential behind it, you've basically let your whole patching team repoint production automation at different secrets if they wanted to. Use-only access keeps "can run this" and "can change what this authenticates as" as two different things.
Where to Actually Create These in AWX
This is the part that trips people up, because it's spread across a few different screens.
Organizations — left sidebar, under Access, then Organizations. Click Add.
Teams — same Access menu, then Teams. Click Add, name it, pick which organization it belongs to. Once it's created, open it up — there's a Users tab to add members, and a Roles tab where you actually give that team permission to do something.
Users — Access, then Users. You can add people directly here, or they'll show up automatically if you're using LDAP, SAML, or some other single sign-on. Open a user and you'll find a Teams tab and a Roles tab on their profile too.
Giving a team access to something specific — this is the step people miss, because it's not on the Teams page at all. You go to the actual thing — a job template, a credential, an inventory — and open its Access tab. From there you add the team and pick a role. Same pattern everywhere: open the resource, go to Access, add the team, choose Admin or Execute or Use or Read.
So building this out in practice goes: create the organization, create your teams inside it and add people, then go through your job templates, credentials, and inventories one at a time and grant the right team the right role from each one's Access tab. There's no single screen showing everything a team can touch — if you want that full picture, open the team itself and check its Access tab, which lists everything it currently has rights to.
Why This Matters for the Patch Workflow
Once a job template can stop production IRIS, this stops being a nice-to-have. The team running the monthly patch should be able to do it confidently and see exactly what happened — but they shouldn't be able to quietly change the order it stops nodes in, or swap which credential it's using. Getting this right is what lets you hand routine patching off to a wider team without it turning into a trust exercise every time someone clicks Launch.
Top comments (0)