Notifications
Clear all
Topic starter
08/07/2026 7:00 pm
TL;DR: Managing passwords and keys in automation requires explicit governance around availability, key protection, and least-privilege access, according to PassBolt. The practical issue is not automation itself, but whether secrets handling, auditability, and lifecycle controls keep pace with infrastructure code.
NHIMG editorial — based on content published by Passbolt: Managing Secrets in Ansible using Passbolt
By the numbers:
- Only 44% of organisations are currently using a dedicated secrets management system.
Questions worth separating out
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.
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.
Q: What do teams get wrong about secret rotation in infrastructure code?
A: They often rotate the value but leave the retrieval model unchanged.
Practitioner guidance
- 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.
- 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.
- 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.
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
👉 Read Passbolt's guide to managing Ansible secrets with Passbolt →
Ansible secrets management: what IAM teams need to watch?
Explore further
08/07/2026 7:24 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Ansible secrets management still hinges on secrets governance
