Secret Entitlement with Policies
Once secret stores and secret engines are fully configured via the Admin UI or CLI, you may create policies to entitle managed secrets to users and/or groups of users, as well as enforce fine-grained policy-based access control (PBAC) for the users who are entitled to access those managed secrets. Entitlement means using policies to allow specific users or groups of users to access and perform specific actions on managed secrets. Your policy statements can specify the users permitted to access specific secrets and what actions users are permitted to perform, such as reading, retrieving, rotating, or validating managed secrets. These policies can also include annotations (to require users to justify their actions, or receive an MFA challenge) and context-based conditions (such as access based on the user's location) for enhanced control and flexibility.
After such policies are saved, entitlements for managed secrets are shown in the Admin UI in Settings > Secrets Management > Secrets > Entitlements.
The sections that follow describe how to structure policy statements to allow users and/or groups to access and perform actions on managed secrets. For all other information about policies, please see Policies.
Actions for Secrets Management
In a policy statement, StrongDM Secrets Management actions are set in the format StrongDM::ManagedSecret::Action::"<ACTION>", where <ACTION> is the name of the action (for example, StrongDM::ManagedSecret::Action::"rotate").
The possible actions for managed secrets are:
readretrieverotatevalidate
The resource in the policy statement also must be set as resource is StrongDM::ManagedSecret.
In the Policy Editor, if you are typing into the editing area directly, enter the action(s) (and resource) in the following way.
permit (
principal,
action in [StrongDM::ManagedSecret::Action::"retrieve"],
resource is StrongDM::ManagedSecret
);If multiple actions on managed secrets are allowed, enter each action in the following way.
Actions for managed secrets may be set in policy statements in combination with context and annotations. Examples are shown in the next section.
Example Policy Statements for Entitlement and PBAC
This section provides some examples of policy statements that entitle managed secrets to users and groups, as well as enforce policy actions on managed secrets operations.
Allow users to conduct particular Secrets Management actions when the user's employeeNumber matches the managed secret's employeeNumber tag value:
Allow retrieval of managed secrets where the user's employeeNumber matches the value of the managed secret's employeeNumber tag:
Allow users with the "secrets-admin" role to perform public read/rotate/validate actions on managed secrets (note that the role value is the role ID rather than the role name in the example shown):
Allow users with the "production-access" role to perform retrieve/public read/rotate/validate actions on managed secrets tagged with env=production:
Allow users with the "development-access" role to perform retrieve/public read/rotate/validate actions on managed secrets tagged with env=development:
Allow users with the "staging-access" role to perform retrieve/public read/rotate/validate actions on managed secrets tagged with env=development:
Allow retrieve/public read/rotate/validate actions on managed secrets tagged with "owner" equal to the principal's email:
Allow admins to access managed secrets:
Allow all Secrets Management actions on secrets tagged with foo=bar:
Forbid access to managed secrets if there is an error:
Last updated
Was this helpful?

