Notifications
Clear all
Topic starter
08/07/2026 7:00 pm
TL;DR: Secrets automation is moving toward stricter identity binding and less ambiguity, as PassBolt’s rewritten Ansible lookup plugin for v5 now retrieves encrypted metadata, account kits, and richer resource objects through UUID-based lookups, while dropping search-by-name and write operations. The practical lesson is that this changes how teams govern access, retrieval, and playbook design.
NHIMG editorial — based on content published by Passbolt: Ansible lookup plugin is back, rewritten for Passbolt 5
By the numbers:
- Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
Questions worth separating out
Q: How should security teams govern Ansible playbooks that retrieve secrets from a vault?
A: Security teams should treat playbooks as identity-aware consumers of governed objects, not as generic scripts.
Q: Why do encrypted metadata and richer secret objects change NHI governance?
A: Because the store is no longer exposing only a secret value.
Q: What breaks when secret lookup depends on names instead of exact identifiers?
A: Ambiguity breaks first.
Practitioner guidance
- Replace ambiguous secret lookups with UUID-scoped retrieval Update Ansible playbooks so they resolve one exact resource identifier before execution.
- Classify account kits as governed identity material Store account kits and passphrases in a controlled vaulting pattern, and define who can issue, download, and rotate them.
- Validate encrypted metadata handling before migration Test whether your automation can decrypt personal and shared metadata correctly, including key import and verification steps.
What's in the full article
Passbolt's full article covers the operational detail this post intentionally leaves for the source:
- Step-by-step Ansible lookup flow for the rewritten plugin, including the exact call sequence used to retrieve a secret resource.
- Hands-on playground instructions for running the demo stack locally and testing the plugin against sample resources.
- Implementation details for personal versus shared metadata decryption, including the shared-key handling path.
- Code-level discussion of the internal module structure that could later support a broader SDK.
👉 Read Passbolt's article on the rewritten Ansible lookup plugin for v5 →
Passbolt's Ansible lookup plugin and encrypted metadata: what changed?
Explore further
08/07/2026 7:24 pm
Exact-object retrieval is now the governance model for secret automation: Passbolt’s move from search-by-name to UUID-based retrieval reflects a broader identity security trend. Automation becomes safer when the system can point to one unambiguous object, but governance gets harder if inventories are weak or stale. The operational implication is that secret stores and playbooks now depend on the quality of upstream identity records, not just on vault strength.
A few things that frame the scale:
- Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, according to the Ultimate Guide to NHIs.
- Another finding from Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs shows that 71% of NHIs are not rotated within recommended time frames.
A question worth separating out:
Q: Who should own lifecycle controls for account kits and secret retrieval identities?
A: Identity governance and platform teams should own them together. The reason is simple: the kit is both an access artifact and a cryptographic trust package, so its issuance, storage, revocation, and recovery all affect security. Lifecycle discipline is the only way to keep automation aligned with current access intent.
👉 Read our full editorial: Passbolt's Ansible lookup plugin now handles encrypted v5 secrets
