Application identities and CCP-style secret fetch
Enrol a workload as an Application identity — allowed safes, allowed account patterns, a rate limit — and let it fetch a secret at run time by certificate, IP or OS attestation.
An Application identity is what a script, service or workload authenticates as when it fetches a secret from the vault at run time, instead of the secret being hard-coded. The credential vault introduces the idea; this article is the reference for the object itself, the three ways it can prove who it is, and the fetch endpoint shaped after CyberArk's Central Credential Provider (CCP).
What an Application identity holds
An Application has a name, an AppID, the safes it is allowed to fetch from, the account-name patterns it may fetch within those safes, and a rate limit — a hard ceiling on how many times it may fetch per window, so a compromised workload identity cannot turn the vault into an unlimited secret-dispensing oracle. Every fetch attempt against it, successful or refused, is recorded unconditionally.
The three authorisation methods
| Method | What is checked | Strength |
|---|---|---|
| Client certificate thumbprint | The TLS peer certificate's thumbprint, matched against an enrolled value. | The strongest of the three — cryptographic, not a claim the caller makes about itself. |
| Source IP / CIDR | The request's source address, matched against an enrolled range. | Bounded by trusting r.RemoteAddr only — there is no X-Forwarded-For handling, so this is only as strong as the network path directly in front of the fetch endpoint. |
| OS-user / path attestation | A value the calling agent presents in an X-Qorionix-OS-Attestation header, matched against an enrolled string such as k8s:<namespace>/<serviceaccount> (see Kubernetes workload authentication, which reuses this same method). | Self-declared by the calling agent, not cryptographically signed. State this plainly to anyone relying on it: this is the weakest of the three, an attestation rather than a proof, unless the caller reaching it has already been authenticated some other way (as Kubernetes TokenReview does before this method is used for a pod). |
A request is refused if it matches zero enrolled methods, and also refused if it matches more than one — an ambiguous match is treated as a failure to authorise rather than a lucky pass.
The CCP-compatible fetch
GET /api/v1/aap/accounts?safe=<safe>&object=<account>This resolves the (safe, account) pair against your real safes and credentials, then issues the secret through the same policy-governance, rate-limit and audit path the platform's other workload-fetch endpoint already enforces — there is no second, possibly weaker gate for this one. The response shape follows CCP's own convention (Content, UserName, Address, PolicyID), so tooling written against CyberArk's Central Credential Provider needs only the URL and auth method changed, not its parsing logic.
Managing Application identities: /pam/applications
List, create, view and update an Application from the console, including the allowed-safes editor; revoke one entirely; add or rotate an auth method; and view the fetch audit — who fetched what, when, and which attempts failed. This is genuinely a console screen, not an API-only surface: setting up a workload identity and reviewing what it has fetched does not require calling the API by hand.
What to do next
- Prefer the client-certificate method wherever your workload can hold one — it is the only one of the three that is not, at some level, a claim the caller makes about itself.
- Scope every Application's allowed safes and account patterns as narrowly as the workload actually needs, not to the whole vault.
- Check the fetch audit on
/pam/applicationsafter enrolling a new Application, and confirm you see exactly the fetches you expect and nothing else.