Vault, Safe, and Policy Administration
Domain 3 - Vault, Safe, and Policy Administration
This domain tests administration of the CyberArk Digital Vault and Safes in PAM, and policy authoring in Secrets Manager. Keep the control planes distinct: the Vault stores privileged accounts; Safes organize those accounts and permissions; Secrets Manager uses YAML policy to authorize NHIs to variables.
Core rules and concepts
- The Digital Vault is a hardened, encrypted store accessed by PAM components, typically over port 1858. Recovery keys, disaster recovery, dual control, and audit are core operational controls.
- A Safe is a logical container for accounts. Members receive roles such as Safe Admin, Safe Auditor, and End User. Safes also carry retention, CPM, dual-control, and object-level permission settings.
- Secrets Manager policy is policy as code. YAML is loaded with conjur policy load, and branches form a tree. Resources include !variable, !host, !layer, !group, !user, !webservice, and !policy.
- !permit grants privileges on a resource to a role. !grant adds a role to a group or layer. !deny can override a permit. Variable retrieval requires execute; read alone is not enough to fetch the secret value.
- Policy load modes include append, replace, and delete. Replace is appropriate only when the entire branch should be replaced.
Worked example
A policy defines layer ci/pipeline, host ci/runner, variable prod/db/password, a grant making the host a member of the layer, and a permit giving the layer execute on the variable. The reasoning: the host inherits the layer permission through membership; the permit is scoped to one variable; no human user is involved. If the host were not a member of the layer, the permit would exist but retrieval would fail. If the permit granted only read, authentication could succeed while the secret fetch is denied.
Traps that cost marks
- Confusing Safe membership in PAM with Conjur policy authorization; they are different systems.
- Loading replace on a shared branch and deleting resources other teams depend on.
- Granting update or execute broadly across environments instead of per variable and per layer.
- Forgetting that a permit on a layer does nothing for a host that is not a member.
- Ignoring deny precedence and assuming a permit always wins.
- Using a human user account for an application instead of a host identity.