Secrets Management
Centralizing Application Secrets
Secrets management in CyberArk extends the Vault beyond human users to applications and machines. Applications authenticate to the Vault using application authentication methods (e.g., certificate-based or path-based) and retrieve secrets through Central Credential Provider (CCP) or similar interfaces. The central idea is eliminating hard-coded credentials in code and configuration. A common trap is assuming an application can retrieve a password just because it can reach the Vault; it still needs an authorized application identity and safe permissions.
Credential Providers and Rotation
Central Credential Provider serves secrets over a web API to authorized applications. CPM rotates the underlying account passwords per platform policy, so applications must fetch fresh credentials rather than caching them indefinitely. Questions often test that rotation and retrieval are separate concerns: rotation changes the secret; the provider delivers the current one. Another trap is confusing CCP (central, server-side retrieval) with local providers that cache credentials on the host.
Secrets Hygiene
Good practice includes short-lived credentials, least-privilege application identities, and auditing every retrieval. Avoid embedding secrets in source control; instead reference the provider at runtime. Understand that dual control and exclusive access are human-access policies and generally do not apply to machine retrieval in the same way.
Worked Example and Rule of Thumb
A microservice needs a database password. The correct pattern is to register an application identity, authorize it to the safe, and have it call CCP at runtime for the current rotated password, with no secret in code. Rule of thumb: applications authenticate, then retrieve; they never hard-code.
Auditing Retrieval
Every secret retrieval should be logged so anomalous access patterns can be detected.