Controller compromise is fleet compromise · Ansible

Say it once, plainly, and let the rest of the part follow from it:

Compromise of the controller is compromise of every host it manages.

Not “increases risk to”. Not “could lead to”. The controller holds credentials that authenticate as a privileged user on every managed node, and the managed nodes have no way to tell a legitimate run from an illegitimate one. An attacker who has your controller does not need to find a vulnerability in your fleet. They have the mechanism you built for exactly this purpose, working exactly as designed.

That is an uncomfortable sentence and it is the honest one. Everything in this part is an attempt to make it less true, and none of it makes it false.

Why there is nothing to stop them

A managed node’s sshd receives a connection presenting a valid key for an account with sudo. It authenticates the key, grants the session, and escalates. From the host’s point of view, that is a correct and successful authentication.

There is no step at which the host asks whether this run was authorised, whether it came from a pipeline or a laptop, whether it is 03:00 on a Sunday, or whether the change matches an approved ticket. Those questions have no representation in the protocol. The host has one question — is this key permitted for this account — and the answer is yes, because you made it yes.

This is what “agentless” costs. An agent could hold policy: refuse certain operations, require a signed instruction, rate-limit. Ansible has no agent, so there is no policy on the far side. All of the authorisation lives on the controller, which means all of it is lost when the controller is.

What is actually on a controller

Rank the assets by what their loss costs, because that ranking drives every decision in the rest of this part.

Asset	A read gives an attacker	A write gives an attacker
SSH private keys for automation	fleet access as the automation user, usually with `sudo`	replace with their own key
Vault password or its source	every secret in the repository, historic and current	re-encrypt secrets under their key
`ansible.cfg` and inventory	the map of the estate: every hostname, group and role	redirect runs, change the become user, disable host key checking
The playbook repository	your architecture, and often credentials that leaked into it	arbitrary code that runs as root everywhere on next run
Fact cache	inventory of software and versions across the fleet	poisoned facts that change conditional behaviour
`~/.ansible/tmp`, logs	module arguments, which contain passwords	—

Two things stand out from that table.

Read access is not a lesser compromise. Someone who can only read the controller filesystem walks away with the automation private key and the vault password. That is fleet access. The distinction between read and write matters much less here than it does almost anywhere else, which is why Part III’s material on filesystem layout and group permissions is a security control and not housekeeping.

The inventory is a valuable asset by itself. Estates protect credentials and leave the inventory readable, because it “contains no secrets”. It contains the complete topology of the environment, including which hosts are databases, which are in production, and which group has the weakest configuration. Reconnaissance that would otherwise take an attacker weeks is a file.

What you can still do

The framing is deliberately bleak, so it is worth stating what remains possible before the part continues. None of these prevent the outcome; they change its size, its speed, or the odds of noticing.

Reduce what one credential reaches. Separate keys and separate controllers per environment mean a compromise of staging is not a compromise of production. This is the highest-value control available and it is the subject of lesson 4.

Constrain the credential at the far end. authorized_keys options can limit where a key may be used from and what it may run. That is the only authorisation that lives on the managed node rather than on the controller, which makes it the only control that survives controller compromise at all.

Make the controller a poor place to hide. A dedicated host with a small package set and restricted egress is one where unexpected processes and unexpected outbound connections are visible. On a general-purpose workstation they are not.

Make runs accountable. Named accounts, logged runs, and a record of who ran what. This does not stop an attacker; it decides whether you can answer “what did they change” afterwards, which is the difference between a scoped recovery and rebuilding the estate.

Under the hood

It is worth being precise about where the trust actually sits, because the answer is not “in Ansible”.

Ansible has no authentication or authorisation of its own. It shells out to the SSH client, which uses the key material you point it at, and it invokes sudo (or another become plugin) on the target, which consults sudoers there. Every security decision in a run is made by OpenSSH and by sudo, using configuration that lives on the managed node.

That has one genuinely useful consequence. Because the enforcement is OpenSSH and sudo, the controls that work are OpenSSH and sudo controls — authorized_keys restrictions, SSH certificates with principals and expiry, sudoers rules that constrain the automation account. Those are enforced on the managed node, by software that does not trust the controller.

Nothing you configure in ansible.cfg has that property. Every setting there is advice the controller gives itself, and an attacker holding the controller changes it at will. When you are deciding where to invest in this part, that distinction — enforced on the target versus configured on the controller — is the one that predicts which controls survive.

What happens if the vault password is compromised but the SSH keys are not?

You have lost every secret in the repository, including its history, and you have probably not lost direct fleet access.

The distinction is worth drawing because the responses differ. Without the keys, an attacker cannot immediately run a playbook. But the vault contains database passwords, API tokens, service account credentials and monitoring keys — and those authenticate to systems that do not care where the connection came from.

The recovery is also different in kind. Rotating an SSH key is a mechanical operation across a fleet, covered in lesson 5. Rotating everything a vault contained means changing every secret in every system that consumes it, coordinated with the teams that own them, and the vault itself is only the first step. Lesson 6 covers the rekey; the rest is an incident with a project plan attached.

The practical lesson is that vault password custody deserves the same seriousness as key custody, and it usually gets less — because a password in a file looks less dangerous than a private key, and it is not.

Why there is nothing to stop them

What is actually on a controller

What you can still do

Knowledge check