Ansible secrets management still hinges on secrets governance

At a glance

What this is: A practical comparison of how Ansible can manage secrets through Vault, lookup plugins, and Passbolt, with the main finding that secret handling still depends on governance, auditability, and access control.

Why it matters: It matters because infrastructure automation often expands NHI exposure, so IAM teams need to know where secrets live, who can retrieve them, and how rotation and offboarding are controlled.

By the numbers:

• Only 44% of organisations are currently using a dedicated secrets management system.
• The average time to mitigate a leaked secret is 36 hours, highlighting the operational burden of manual remediation processes.

👉 Read Passbolt's guide to managing Ansible secrets with Passbolt

Context

Ansible secrets management is the problem of keeping credentials usable by automation without leaving them embedded in inventories, playbooks, or repositories. In practice, the choice is not just between encryption and lookup plugins. It is about where trust sits in the automation chain, how secrets are retrieved at runtime, and whether the surrounding IAM and NHI controls can still enforce least privilege.

This matters because automation does not remove identity risk. It changes the shape of it: service accounts, private keys, passphrases, and delegated access can become harder to see once they are embedded in orchestration. For IAM and security teams, the real question is whether secrets governance survives the move from manual administration to code-driven operations.

Key questions

Q: How should security teams manage secrets for Ansible automation?

A: Security teams should keep secrets out of static playbooks where possible, retrieve them at runtime from a controlled secrets service, and assign automation a dedicated read-only identity. The key control is not just encryption, but lifecycle ownership. If retrieval, rotation, and offboarding are not explicit, the automation path becomes a hidden access path.

Q: Why do secrets in automation create NHI governance risk?

A: Because the automation identity becomes the thing that can reach the secret, and that identity can often be reused across jobs, hosts, or pipelines. If the account is overprivileged, the risk is not limited to one password or token. It becomes a broader non-human identity problem involving access scope, auditability, and revocation.

Q: What do teams get wrong about secret rotation in infrastructure code?

A: They often rotate the value but leave the retrieval model unchanged. That means old access paths, cached credentials, or broad service account permissions can continue to expose the same secret even after it has been changed. Effective rotation requires both updated secret values and removal of outdated access routes.

Q: Who should be accountable for secrets used by DevOps tooling?

A: Accountability should sit with the team that owns the automation and the secret source together, not with a generic platform group alone. The responsible owner must be able to prove who can retrieve the secret, who can rotate it, and who can revoke it when a job, host, or service account is retired.

Technical breakdown

Ansible Vault vs runtime secret lookup

Ansible Vault encrypts secret values before they are stored in inventory or source control, so the ciphertext can travel with the playbook. A lookup plugin changes the model by retrieving the secret at execution time from an external system such as a vault or secrets manager. That reduces the amount of sensitive material written into code, but it does not eliminate the dependency on the retrieval path, authentication material, or the privileges behind the lookup. The main architectural distinction is whether secrecy is preserved statically in files or dynamically at runtime.

Practical implication: treat lookup-based retrieval as a control boundary that needs its own access policy, not as a substitute for secrets governance.

Passphrase protection, gpg-agent, and delegated cryptography

The article’s Passbolt example highlights a familiar pattern in secrets handling: the secret store is only one layer, while the private key and passphrase that unlock access are often the higher-value assets. Using gpg-agent delegates cryptographic operations away from stored plaintext variables and into a keyring-backed workflow, which reduces direct exposure in repositories. But that also shifts trust to host configuration, local session handling, and the operational discipline around key management. In other words, the security model becomes stronger only if the surrounding system preserves the assumptions the cryptography depends on.

Practical implication: separate key material from automation code and document exactly which host or session components can unlock secrets.

Dedicated technical accounts and read-only retrieval

The article recommends a dedicated Passbolt user account with read-only access, which is the right identity pattern for automation that only needs to fetch secrets. This is an NHI governance issue, not just a convenience choice. The account should be scoped to the minimum resource set, tied to a clear operational owner, and reviewed like any other non-human identity. If the same account can both read and modify resources, the blast radius expands from secret retrieval into secret governance itself. The control objective is to keep the automation identity narrow, observable, and easy to revoke.

Practical implication: provision a dedicated read-only service account for secret retrieval and review its access like any other NHI.

NHI Mgmt Group analysis

Secrets management in automation is still an identity problem, not a tooling problem. Ansible can encrypt values, fetch them from a secrets service, or delegate cryptographic work to a local agent, but each pattern still depends on who or what is allowed to retrieve the secret. That means the real governance question is which NHI is trusted to act at runtime and how narrow that trust remains. Practitioners should treat the retrieval identity as part of the control plane, not just the secret store.

Read-only automation identities are a governance requirement, not an implementation detail. The article’s advice to use a dedicated technical account is the right model because automation should not inherit broad write privileges simply because it is convenient. This is where NHI governance and PAM meet: the account must be scoped, reviewed, and revoked like any other privileged identity. The practitioner conclusion is straightforward: if the account can change the secret system, it can also undermine it.

Centralisation improves visibility, but it also creates a single operational dependency. Moving from scattered inventory secrets to a central secrets repository makes audit trails and rotation easier, yet it concentrates availability risk into the system that automation now depends on. That trade-off matters for NHI governance because the secret store becomes a critical identity service for machine access. Teams should evaluate resilience, break-glass procedures, and failure modes alongside access policy.

Secret rotation only works when lifecycle ownership is explicit. The article’s emphasis on direct rotation inside the secret system points to a broader lifecycle issue: a secret that can be changed in one place but consumed in many automation paths still needs clear ownership, revocation logic, and audit evidence. In identity terms, the secret is only one artifact in the lifecycle. Practitioners should map provisioning, retrieval, and offboarding together so stale access does not survive the code path.

Identity blast radius: automation reduces manual handling but can widen hidden exposure paths. When secrets are pulled into playbooks, environment variables, or agent-backed workflows, the risk shifts from visible storage to invisible runtime handling. That creates a blast radius problem where one compromised technical account, host, or pipeline can expose multiple downstream credentials. The practitioner implication is to map every retrieval path and reduce the number of identities that can touch high-value secrets.

From our research:

• Only 44% of organisations are currently using a dedicated secrets management system, according to The 2024 State of Secrets Management Survey.
• 54% of organisations are dissatisfied with their current secrets management solution because not all secrets are secured, and 43% cite lack of central management.
• See Guide to the Secret Sprawl Challenge for the governance patterns that help move from scattered secret handling to controlled lifecycle management.

What this signals

Secret sprawl is now a lifecycle problem, not just a storage problem. When automation teams spread credentials across inventories, keyrings, and external stores, the governance question becomes whether each secret has an owner, a retrieval path, and an offboarding event. That is why centralisation should be paired with lifecycle controls and a clear review cadence, not treated as the finish line.

For IAM and PAM teams, Ansible-style automation raises the same question seen in broader machine identity programmes: can you prove which non-human identity can retrieve which credential at any point in time? If not, the organisation has visibility into files, but not into effective access.

A useful design pattern is to align secret retrieval with the NIST Cybersecurity Framework 2.0 functions and the OWASP Non-Human Identity Top 10, because runtime access, rotation, and revocation are all identity controls. The programme signal to watch is whether access can be granted and removed without changing automation code.

For practitioners

• Use dedicated read-only technical accounts for secret retrieval Scope automation identities to the smallest set of resources they need, and separate retrieval permissions from secret administration. Review those accounts on the same cadence as other privileged non-human identities.
• Move secret material out of source control where possible Prefer runtime lookup from a controlled secrets service over storing sensitive values directly in inventories or playbooks. Where encrypted files remain necessary, limit who can decrypt and where the decryption keys are held.
• Document the full retrieval path for every automation secret Track which host, keyring, agent, or environment variable can unlock each secret, then test whether those components are covered by logging, rotation, and revocation controls.
• Build resilience around the secrets dependency Treat the secrets service as an operational dependency of automation and define fallback handling, disaster recovery, and access continuity procedures before it becomes a bottleneck.

Key takeaways

• Ansible secrets management is really about governing the identities that retrieve secrets, not just encrypting values at rest.
• Dedicated read-only automation accounts, runtime lookup, and explicit lifecycle ownership are the controls that keep secret handling from becoming hidden privileged access.
• Centralised secret storage improves auditability, but only if resilience, recovery, and revocation are designed into the automation dependency chain.

Key terms

• Automation identity: A non-human identity used by scripts, pipelines, or orchestration tools to perform work without a person present. In practice, it must be governed like any other identity: scoped, logged, rotated, and revoked when the automation or its purpose changes.
• Runtime secret retrieval: A pattern where automation fetches credentials at execution time instead of storing them in code or configuration files. It reduces static exposure, but the retrieval path, hosting environment, and authentication material still need identity controls.
• Secret sprawl: The uncontrolled spread of passwords, keys, tokens, and certificates across repositories, inventories, hosts, and tools. It creates weak visibility and makes rotation, audit, and offboarding harder because no single owner can consistently prove where each secret lives.

What's in the full article

Passbolt's full article covers the operational detail this post intentionally leaves for the source:

• Exact Ansible lookup plugin syntax for Passbolt resource retrieval and filtering
• Environment variable examples for authentication with and without gpg-agent
• GitHub repository and docker-compose walkthrough for the hands-on demo environment

👉 Passbolt's full article covers the lookup plugin setup, authentication options, and working playbook example.

Deepen your knowledge

NHI governance, machine identity security, and secrets management are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.