Passbolt’s Ansible lookup plugin now handles encrypted v5 secrets

At a glance

What this is: Passbolt has rewritten its Ansible lookup plugin for version 5 to support encrypted metadata, account kits, and richer secret retrieval.

Why it matters: It matters because secrets automation is becoming more identity-bound and more explicit, which affects how IAM, NHI, and platform teams design retrieval, governance, and auditability.

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.
• 27 days

👉 Read Passbolt's article on the rewritten Ansible lookup plugin for v5

Context

Secrets retrieval in automation only works cleanly when the identity boundary is explicit. In this article, Passbolt argues that its rewritten Ansible lookup plugin had to change because Passbolt 5 encrypted metadata by default and introduced account kits, which means playbooks now depend on stronger identity binding rather than loose name-based searching.

For IAM and NHI programmes, the important shift is not the Ansible syntax. It is the move from ambiguous lookup patterns to UUID-scoped retrieval, encrypted account material, and signed verification steps that make access paths easier to reason about but also more rigid to operationalise.

That is a typical trajectory for secrets tooling: convenience features give way to tighter identity and cryptographic guarantees as the platform matures. Teams that rely on automation need to treat those guarantees as part of governance, not just implementation detail.

Key questions

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. The playbook should resolve exact resource identifiers, validate cryptographic trust, and avoid embedding long-lived credentials in environment variables. The key control is deterministic access, which makes review, logging, and offboarding much easier to manage.

Q: Why do encrypted metadata and richer secret objects change NHI governance?

A: Because the store is no longer exposing only a secret value. It is exposing identity-linked metadata, shared-key relationships, and object structure that can reveal sensitive context. Governance must therefore cover the whole resource object, including how it is named, resolved, decrypted, and shared across users or automation.

Q: What breaks when secret lookup depends on names instead of exact identifiers?

A: Ambiguity breaks first. When multiple records share the same name, playbooks can fetch the wrong object, operators can approve the wrong entitlement, and audits lose traceability. Exact identifiers reduce that risk by forcing the automation to target one known object, which is essential when secrets become part of a controlled lifecycle.

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.

Technical breakdown

Why UUID-based lookup replaces name-based search

Passbolt’s new plugin requires the resource UUID rather than a search term such as name, username, or URI. That changes the lookup model from fuzzy discovery to exact selection. In practice, this reduces ambiguity when multiple resources share the same label, but it also shifts the burden upstream to inventory hygiene and reference management. The playbook no longer discovers secrets by interpretation; it retrieves a specific object that must already be known. This is a common pattern when secret stores mature: the interface gets stricter because identity precision matters more than convenience.

Practical implication: maintain an authoritative resource inventory so playbooks can resolve UUIDs deterministically before execution.

How encrypted metadata changes secret retrieval

In Passbolt 5, the metadata itself can be encrypted, not just the secret value. The plugin therefore has to decrypt two layers: first the metadata object, then the secret payload. If the metadata key is personal, the process is straightforward. If it is shared, the plugin must fetch the shared metadata key, verify which copy is meant for the user, import it into the local keyring, and only then decrypt the resource. This adds cryptographic integrity checks to what used to be a plain retrieval path.

Practical implication: validate whether your automation can safely handle encrypted metadata before you migrate playbooks or refactor access workflows.

Why account kits and signed verification matter

The account kit bundles the private key, domain, identity, and security token into a signed file. The plugin verifies that signature before any network call, then validates the passphrase and confirms the server fingerprint during authentication. That sequence matters because it establishes trust before retrieval begins. In other words, the automation is not merely reading a secret store. It is proving that the file, the user identity, and the server all match the expected cryptographic relationship before a token is issued.

Practical implication: treat account kits as governed identity material and protect them with the same controls you apply to other high-value credentials.

NHI Mgmt Group analysis

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.

Encrypted metadata creates a second trust boundary inside the secret store: Once metadata is encrypted, the lookup path is no longer a simple read from a repository. The automation must prove it is allowed to see the object identity before it can see the object contents. That is a useful control pattern for NHI governance because it limits accidental disclosure, but it also means every downstream workflow has to understand metadata as sensitive identity material, not just descriptive text.

Account kits show how identity material is becoming packageable and portable: A signed bundle that carries keying material, domain context, and authentication data makes non-human access easier to move, but also easier to mishandle. This is where lifecycle governance becomes critical: the access artifact itself now has a lifecycle, and the programme needs to track issuance, storage, rotation, and revocation as one governed chain.

Secrets automation is converging with NHI lifecycle control: The plugin’s read-only design, its emphasis on signed verification, and its removal of ambiguous lookup all point to the same direction. Secret retrieval is no longer just an integration task. It is an NHI control point, and the teams that govern it need to think in terms of object identity, cryptographic trust, and offboarding discipline.

Named concept. identity binding drift: This article illustrates the gap that appears when automation relies on loosely identified secrets instead of cryptographically bound objects. That drift weakens auditability and increases retrieval ambiguity. The practitioner conclusion is that the more sensitive the automation, the less room there is for guesswork in how identities and secrets are referenced.

From our research:

• 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.
• That lifecycle gap is exactly why automation teams should pair exact-object retrieval with offboarding discipline, not treat lookup tooling as a one-off integration.

What this signals

Identity binding is becoming the real control plane for secret automation: As more platforms move from name-based lookup to exact-object retrieval, the programme risk shifts from accidental discovery to identity hygiene. Teams should expect playbooks, vaults, and ticketing workflows to become more dependent on authoritative object records and lifecycle discipline.

The practical consequence is that account material, lookup identifiers, and metadata permissions now behave like governed identity assets. If your secret store cannot distinguish between descriptive data and sensitive object identity, your access model will drift faster than your review cycles can correct it.

With 96% of organisations still storing secrets outside secret managers in vulnerable locations, per the Ultimate Guide to NHIs, the gap is not theoretical. Exact retrieval helps, but only when the surrounding programme can also enforce issuance, rotation, and revocation consistently.

For practitioners

• Replace ambiguous secret lookups with UUID-scoped retrieval Update Ansible playbooks so they resolve one exact resource identifier before execution. Remove name-based assumptions from secret retrieval paths, and make UUID mapping part of the approved inventory process.
• 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. Treat the account kit as part of the non-human identity lifecycle, not as a convenience file.
• Validate encrypted metadata handling before migration Test whether your automation can decrypt personal and shared metadata correctly, including key import and verification steps. Do not assume older lookup patterns will work once metadata encryption becomes the default.
• Remove write expectations from secret retrieval tooling Separate lookup-only workflows from any provisioning or update logic. If teams need to create or rotate records, handle that through governed admin processes rather than overloading retrieval automation.

Key takeaways

• Passbolt's rewritten lookup plugin shows secret automation moving toward exact-object retrieval, encrypted metadata, and stronger cryptographic trust checks.
• The key governance issue is not the Ansible syntax change but the need to manage secret identities, account kits, and metadata as controlled lifecycle assets.
• Teams that rely on automation should align inventory, lookup precision, and offboarding discipline before they expand encrypted secret workflows.

Key terms

• Account Kit: A signed identity package used to bootstrap access to a Passbolt account. It bundles keying material, domain context, and related authentication data so a client can validate trust before attempting retrieval or login. In governance terms, it is a sensitive access artifact with its own lifecycle.
• Metadata Encryption: A protection model where the descriptive fields around a secret, not just the secret value itself, are encrypted. This limits exposure of names, URIs, and other context that can reveal how a secret is used. It also forces automation to prove access earlier in the retrieval flow.
• UUID-Scoped Lookup: A retrieval pattern where automation requests one exact resource by unique identifier instead of searching by name or other labels. It reduces ambiguity, improves auditability, and prevents accidental selection of the wrong object. It is especially useful when multiple secrets share similar descriptions or roles.
• Shared Metadata Key: A key that allows multiple authorised users to decrypt metadata for a shared secret resource. It introduces a secondary trust path because the automation must first retrieve and verify the shared key before it can decrypt the object. That makes key handling and lifecycle control especially important.

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.

👉 Passbolt's full post covers the new metadata decryption flow, account kit handling, and demo setup details

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.