CyberArk SECRET-SEN cheat sheet

Nonhuman identity (NHI) is any machine-held credential: service accounts, API keys, certificates, tokens, SSH keys, and secrets used by applications, scripts, containers, and CI jobs.

Secrets management objective: eliminate hardcoded credentials by centralizing storage, enforcing access policy, rotating on a schedule, and auditing every retrieval.

Secret sprawl indicators: credentials in source code, config files, wikis, chat, build logs, and spreadsheets; each copy is an unmanaged identity that survives rotation of the original.

Rotation reduces exposure window; the exposure window equals the time between compromise and rotation, so rotation frequency should match credential privilege and blast radius.

Least privilege for NHI: each application identity gets only the safes and accounts it needs, with no interactive human access unless explicitly required.

Static secrets remain valid until rotated; dynamic secrets are generated on demand with a TTL and expire automatically, removing standing privilege.

Secret Zero problem: the first credential an application uses to authenticate to the vault must itself be protected, typically via platform identity, certificate, or workload attestation.

Defense in depth layers: network isolation of the vault, authentication of the requesting workload, authorization by policy, and tamper-evident audit of each access.

Shared accounts break accountability because audit records show the account, not the individual or workload that used it; unique identities per consumer restore attribution.

Core components: the Digital Vault (encrypted secret store), Central Policy Manager (CPM, rotates and reconciles passwords), Privileged Session Manager (PSM, proxies sessions), and Password Vault Web Access (PVWA, UI/API).

The Vault stores data in an encrypted file system; the Server Key protects the Vault and is held by the administrator, while data encryption keys are stored inside the Vault.

High availability uses Vault replication in an active-passive cluster; the CPM, PVWA, and PSM are stateless components that can be load-balanced and scaled horizontally.

CPM connects to target systems over the network using platform plugins; it needs network reachability and a privileged account with rights to change passwords on each target.

Platforms define how a credential is managed: password change plugin, reconciliation, verification, and rotation interval; account-specific settings can override platform defaults.

Network placement rule: Vault in a restricted zone, CPM/PSM/PVWA in a mid-tier zone, targets in production; firewall rules allow only required ports between tiers.

Disaster recovery requires a Vault backup plus the Server Key and recovery key material; without the Server Key a backup of the Vault cannot be opened.

Component health checks: CPM service status and last rotation timestamps, Vault replication lag, PVWA API responsiveness, and PSM connector availability.

Hierarchy: Vault > Safe > Account. A safe is the container that holds accounts and objects; authorization is granted on safes, not on individual accounts.

Safe permissions are cumulative across safe membership and group membership; a user receives the union of permissions from all groups they belong to.

Standard safe permissions include Use accounts, Retrieve accounts, List accounts, Add/Update/Delete accounts, Manage safe, and Manage safe members.

Retrieve password versus Use password: Use allows the CPM/PSM to connect and inject the credential without revealing it; Retrieve exposes the cleartext value to the user or API caller.

Master policy governs Vault-wide rules such as password complexity, rotation intervals, session recording, and dual control; platform settings then safes then accounts narrow it.

Dual control (approval workflow) requires one or more authorized approvers before a request is fulfilled; it applies to defined actions such as retrieving a password.

Sensitive safe membership rule: keep Manage safe members restricted, because that permission lets a user grant others access and is effectively an escalation path.

Account onboarding requires a platform, a safe, and the target address plus credential; unreconciled accounts show as failures until the CPM verifies the stored password works.

Application access methods: Central Credential Provider (CCP) REST API, Application Server Credential Provider (ASCP) local agent, and SDKs; each authenticates the requesting application before returning a secret.

CCP authorization is based on an allowed machine identifier: the application sends an AppID plus a source identifier (IP, hostname, or certificate) that must match the allowed machines list.

CCP request pattern: GET to the AIMWebService endpoint with AppID, Safe, and Object query parameters; the response contains the username and password as XML or JSON.

Certificate authentication is preferred over IP-based AppID authentication because certificates are harder to spoof and survive infrastructure changes.

CI/CD integration rule: pipeline jobs authenticate to the vault with a short-lived identity (OIDC token, workload identity, or certificate), never with a static secret stored in the pipeline definition.

Dynamic secrets for pipelines: request a just-in-time credential with a TTL, use it for the build or deploy step, and let it expire rather than persisting it.

Secrets must never be echoed into build logs; masking rules help but do not replace fetching at runtime and keeping values out of environment dumps.

ASCP caches credentials locally for a configured period with an encrypted cache, reducing calls to the Vault but widening exposure if the host is compromised.

Every retrieval, password change, and session is written to the Vault audit log; records include user, source, target account, action, and timestamp.

Audit records are stored in the Vault and can be forwarded to SIEM; the Vault audit log is the authoritative record because it is tamper-evident.

Reports to review: accounts not rotated within policy, accounts failing verification/reconciliation, safes with excessive membership, and orphaned accounts whose owner left.

Remediation priority order: credentials exposed in code or logs first (rotate immediately), then standing privileged credentials, then shared accounts, then unused accounts.

Secret scanning in repositories detects committed credentials; finding one requires rotation, not just deletion, because git history retains the value.

Access certification: periodically review safe memberships and privileged group membership, revoking access that is no longer justified by role.

Session monitoring records PSM sessions and can flag commands against a policy; recordings support investigation of privileged activity.

Compliance evidence for audits: rotation evidence, access reviews, session recordings, and audit log exports mapped to the control that requires them.