RBAC as a blast-radius control · Ansible

This course has spent thirty-eight parts on one idea: know which hosts you are about to change, and make it hard to change more of them than you meant to.

Every mechanism so far has been technical. --limit. A precise hosts: line. A guardrail that asserts on the environment. A canary before the fleet.

RBAC is the same idea applied to people. And the failure it prevents has exactly the same shape:

A playbook with no --limit targets every host it can reach.

An operator with no permission boundary targets every host they can reach.

“Everyone can run everything against production” is not a governance problem that happens to involve Ansible. It is a blast-radius defect, identical in structure to the YAML one, and it should offend you in the same way.

The four permissions

A run depends on four separable things. Most estates collapse them into one, and the collapse is the defect.

Question	What it controls	Held by
Who may edit the automation?	What the run does	The people who write and review the code
Who may run it?	Whether it happens, and when	The people responsible for the service
Against which inventory?	How many hosts, and which	Deliberately narrower than the above
With which credentials?	What privilege it holds on those hosts	Narrower still

Read them as a sentence: this person may run this automation against these hosts with this privilege. Change any one of the four and you have a different blast radius.

The reason to separate edit from run is the one that convinces people: they are held by different populations for different reasons.

An application team knows when their service can be restarted. They should be able to run the restart. They should not be able to change what “restart” means for the whole fleet, because that change affects services they do not own and cannot test.

Conversely, the platform engineer who wrote the role may have no business initiating a restart in a payments environment on a Friday afternoon. Their expertise is the code. It is not the change window.

What the roles actually are

The AWX and automation controller role vocabulary is small. The system level has two:

System Administrator — manages all aspects of the system.
System Auditor — views all aspects of the system.

At the object level, the roles that carry the weight:

Role	Grants
Admin	Full management of the object — organizations, teams, inventories, projects, job templates
Execute	Runs an assigned job template. Not edits it
Read	Views the object
Use	Uses the object in a job template — credentials, inventories, projects, instance groups
Update	Updates a project from source control, or an inventory from its source
Ad Hoc	Runs ad hoc commands against an inventory
Member	Membership in an organization or team

Plus organization-scoped administrative roles — Project Admin, Inventory Admin, Credential Admin, Notification Admin, Workflow Admin — each granting create, read, update and delete for one resource type within one organization.

Two of these deserve attention because they are the mechanism the whole design rests on.

Execute is the separation of edit from run. Execute on a job template lets somebody launch it and see the result. It does not let them change the playbook, the inventory, the limit, or the credentials. They can push the button; they cannot change what the button does.

Use is the separation of authenticate from read. Use on a credential lets somebody attach it to a job template without seeing its value. That is a real security property and it gets lesson 4 to itself.

Designing the matrix

The mechanical part is easy once the four questions are separated. Take a concrete estate: three environments, four teams.

Team	Dev inventory	Staging inventory	Production inventory
Platform engineering	Admin on templates and project	Admin	Execute on templates; no edit in the production organization
Application team A	Execute on team A templates	Execute on team A templates	Execute on team A templates, limited to the `app_a` inventory
Database team	Execute	Execute	Execute on database templates only, with the database credential
Support / on-call	Read	Read	Execute on a named set of remediation templates; Read on everything else

Three properties of this matrix are worth naming, because they are what distinguish a design from a list.

No cell grants edit in production. The production organization has no Admin except a break-glass account. Changing production automation means changing it in git, having it reviewed, and letting the project checkout pick it up. That is the point of separating the project from the template.

Application teams are bounded by inventory, not by intention. Team A cannot target databases because the inventory attached to their templates does not contain any. There is nothing to type that reaches a database host. Compare this with a runbook sentence saying “team A should not touch databases”, which is a hope.

On-call has Execute on a named set. Not on everything, and not on nothing. The named set is the remediation templates that have been reviewed for exactly this: safe to run at 04:00 by somebody who did not write them.

The same separation with no platform

Every property above has a version available on a plain controller. It is weaker in one specific way, discussed below, but it is not nothing — and the design work is identical, which is the reason to do this exercise regardless.

Separate inventories per environment and per team. This is the foundation and it is free. The blast radius of a run is the inventory it loaded; a team whose runs load only inventory/app_a/ cannot reach a database.

Separate the credentials. One SSH key per environment, one vault identity per environment, and the production key readable only by the production automation account. Part XXI covered the vault side; Part XLVII covers key custody in depth.

Use sudo to grant the invocation rather than the shell. This is the closest CLI analogue to Execute, and the one most teams miss:

# /etc/sudoers.d/ansible-jobs
%app-a ALL=(ansible-app-a) NOPASSWD: /srv/ansible/jobs/restart-app-a.sh

The app-a group may run one wrapper script as the ansible-app-a account. They may not read that account’s SSH key, edit the script, or run anything else as that account. That is Execute-without-edit, built out of sudo.

Separate the controllers where the separation must be real. Two hosts, two automation accounts, two sets of keys: one that can reach production, one that cannot. This is the only version of the separation that survives a compromised operator account, and for high-value environments it is worth the second VM.

Why the CLI version is genuinely weaker, and by exactly how much

Be precise about the gap rather than pretending it does not exist.

A platform enforces permissions at the point of execution, inside a process the operator does not control. The operator interacts with an API; the API decides what runs; the credentials are decrypted by the platform after the decision.

Every CLI equivalent enforces permissions at the point of access to a file — a key, a vault password, a script — on a machine where the operator has a shell.

That difference has one concrete consequence, and it is the whole gap:

On a shared controller, anyone who can use a credential can read it.

If ansible-playbook can read /etc/ansible/vault/production when you run it, so can cat. If your SSH agent holds the production key while your playbook runs, it holds it for ssh too.

Read-only / Safeuse implies read, on a controller— Verified on ansible-core 2.21.3 in a scratch directory with a fake secret. The password file that lets a playbook decrypt the vault also lets any other command decrypt it.

$ ansible-vault view --vault-password-file .vault-pass secrets.yml

---
db_admin_password: REPLACE_ME_DB_PASSWORD

The sudo construction narrows this usefully: if the vault password file is readable only by ansible-app-a, and app-a may only run one non-modifiable script as that account, then app-a cannot read the secret. That is a real boundary, and it is why the script ownership rules in the callout above are not pedantry — they are the entire enforcement.

What it still cannot survive is an operator with an interactive shell as the automation account, or with sudo to root. On a controller, root is every credential the controller holds. That is not a defect you can configure away; it is why Part XLVII treats controller compromise as fleet compromise, and why the highest-value estates put the decision-making process on a machine the operators do not have shells on.

What happens if the on-call engineer needs to run something they lack permission for, at 03:00?

They will get it done. The only question your design controls is whether the route is one you built.

If there is no defined path, they will find one: a shared account whose password is in the team password manager, a colleague woken up to run it, or the observation that the platform host has SSH enabled and the automation account has an authorised key.

So build the path, and make it noisy rather than difficult:

A break-glass account with real credentials. Not a lesser account that cannot fix the problem — that just guarantees the workaround.

Alerting on use, not approval before use. An approval gate at 03:00 means either a rubber stamp or an outage extended by the length of a phone call. An alert that fires into the incident channel the moment the account authenticates achieves the accountability without the delay.

A review the next working day. Every break-glass use gets read by a human within one business day, with the same question as a guardrail override: was the permission wrong, or was the situation genuinely exceptional? Three uses in a quarter for the same reason means the normal permission is wrong.

The failure mode to design against is not the engineer who uses break-glass. It is the estate where nobody has used it in two years — which usually means it does not work, or an easier undocumented route exists and everyone is using that instead.

Knowledge check

Why this matters

The reason RBAC belongs in a course about blast radius, rather than in a governance appendix, is that it is the only control on this list that scales with the organisation rather than the fleet.

--limit protects one run. A guardrail protects one playbook. A canary protects one rollout. All of them depend on the person at the keyboard using them, and all of them are one hurried night away from being skipped.

A permission boundary protects every run by every person indefinitely, including the ones nobody anticipated, including the runs made by the person who joins next month and has not read the runbook. It is the only control in this course that keeps working when the operator is careless, new, or in a hurry — which is to say, the only one that keeps working during an incident.

That is also why the design work is worth doing when you have no platform at all. Separate inventories, separate credentials, separate automation accounts and a sudo rule naming a script are a weaker enforcement of the same model, and building them forces you to answer the question that matters most: for each person who can change production, exactly how many hosts can they reach?

If you cannot answer that in numbers, the permission model is decoration regardless of which product is enforcing it.