Secrets Management Fundamentals and Nonhuman Identity Security
Domain 1 - Secrets Management Fundamentals and Nonhuman Identity Security
This domain tests whether you can explain why machine credentials need a lifecycle distinct from human passwords, and how CyberArk Secrets Manager treats applications, containers, scripts, and CI/CD jobs as nonhuman identities (NHIs). Expect questions on secret types, risk, secret zero, and the control objectives behind centralization.
Core rules and concepts
- An NHI is any identity that is not a person: service accounts, workloads, bots, RPA, containers, serverless functions, and pipelines. Each needs an owner, a purpose, and constrained permissions.
- Secrets include passwords, API keys, OAuth tokens, SSH keys, certificates, and connection strings. They differ in rotation mechanics and blast radius, so one rotation policy does not fit all.
- Control objectives are central storage, least privilege, authentication before authorization, short-lived credentials where possible, rotation and revocation, auditability, and separation of duties.
- Static secrets remain valid until changed; dynamic secrets are issued on demand and expire. Dynamic or short-lived credentials reduce exposure but still need policy and audit.
- Secret zero is the bootstrap credential a workload uses to prove identity before it can fetch its first secret. Solve it with platform identity such as JWT/OIDC, Kubernetes service accounts, or cloud IAM roles, not with a stored API key.
- Secrets Manager and PAM overlap but are not the same. PAM manages human privileged access and vaulted accounts; Secrets Manager authenticates workloads and delivers secrets through APIs, SDKs, and Summon. They integrate, but the control planes and audiences differ.
Worked example
A pipeline stores an AWS access key as a repository variable. The reasoning: this is a long-lived static secret with no workload identity, so anyone with repository access can use it and rotation is manual. Replace it with GitHub OIDC to a Conjur authn-jwt authenticator. Policy grants the JWT-authenticated host execute on only the required variable. The pipeline fetches at runtime, the old key is rotated and revoked, and audit now identifies a host rather than a shared key.
Traps that cost marks
- Treating rotation as sufficient while leaving the secret over-privileged or shared across workloads.
- Granting every host access to one shared variable instead of scoping by layer and environment.
- Forgetting secret zero and reintroducing a hardcoded bootstrap credential.
- Assuming Kubernetes Secrets are a vault; by default they are base64-encoded API objects, not a governed secret store.
- Confusing authentication, which proves identity, with authorization, which permits retrieval.