Secrets Vault Access Policies
The Secrets Vault supports Role-based Access Control (RBAC) Policies. Access to secrets is denied by default, and must be explicitly granted through Access Control Policies.
Roles
Roles define actions or operations that can be performed on the Secrets Vault and secrets. The following pre-defined roles are supported:
Vault Admin Role
Vault administrators have full access to all aspects of the secrets vault. This access includes:
-
Box management—Can create and manage boxes.
-
Secret management—Can create and manage secrets within boxes, and checkout secrets.
-
Policy management—Can create role-based access control policies to allow users or applications the ability to access secrets.
-
View audit logs—Can view audit logs.
Vault User Role
The vault user role is assigned to users and applications who need access to the secrets. They have the following permissions:
-
List box IDs—Can retrieve the list of boxes (the box name and ID only) that the user or application has been granted access to.
-
List secrets—Can retrieve the list of secrets that the user or application has been granted access to.
-
Checkout secrets—Can retrieve the secret value.
-
Checkin secrets—Can checkin the secret after use.
-
List my checkouts—Can retrieve the outstanding secret leases for the user or application.
-
Get secret metadata—Can retrieve secret metadata such as description and tags, for secrets that the user is granted access.
Vault Box Admin Role
Vault box administrators can perform various tasks on boxes they are allowed to administer, including:
-
Box management—Update box properties and tag boxes.
-
Secret management—Can create and manage secrets, and checkout secrets within boxes they can administer.
Note that the Vault Box Admin cannot checkout secrets by default (they must be part of the relevant Vault User Policy) -
Leases—View and delete checkout leases pertaining to secrets in the box administered by box administrator.
-
View audit logs—Can view and download audit logs.
A summary of the roles and permissions:
Action | Vault Admin | Box Admin | Vault User |
---|---|---|---|
Create Box | Yes | No | No |
Update Box properties | Yes | Yes - on boxes they are allowed to administer | No |
Tag/Untag Box | Yes | Yes - on boxes they are allowed to administer | No |
Delete Box | Yes | No | No |
Create Secret | Yes | Yes - on boxes they are allowed to administer | No |
Update Secret properties | Yes | Yes - on boxes they are allowed to administer | No |
Tag/Untag Secret | Yes | Yes - on boxes they are allowed to administer | No |
Update Secret value | Yes | Yes - on boxes they are allowed to administer | No |
Delete Secret | Yes | Yes - on boxes they are allowed to administer | No |
Checkout Secret | Yes - should be part of a Vault User Policy providing access to the secret | Yes - should be part of a Vault User Policy providing access to the secret | Yes - should be part of a Vault User Policy providing access to the secret |
Create Policy | Yes | No | No |
Update Policy | Yes | No | No |
View Audit | Yes | Yes - only those audits corresponding to Boxes & Secrets within the Boxes administered | No |
Download Audit | Yes | Yes with restrictions same as above | No |
Policies
Vault administrators can create and manage access control policies that manage access to the secrets. Policies consist of the following:
- Security principle—The list of users governed by this policy. This can be an individual local user, an AD user or an AD group.
- Role—The permissions or a list of actions/operations that are granted to the user. Only the vault user role is supported. For information on granting the vault admin role, see Default Admin Policy.
- Resources—The list of boxes and secrets in the vault that the user or group can access.
The maximum number of policy change versions that can be kept is 25.
Note: If you modify a policy and a user is logged on to a session using the policy, the policy changes are not applied to the active session; the changes are applied the next time the user starts a session.
Default Admin Policy
When a new vault is created in KeyControl, the secrets vault creates a default admin policy that grants the vault administrator role to the local user, AD user, or AD group that is set as the first vault administrator. The default admin policy is the only policy you can use to grant the vault admin role to other users. To do so, the Vault Administrator can edit the 'security principle' part of the default admin policy to grant the vault administrator role to additional users.
Vault User Policy
The Vault User Policy provides checkout/access permissions to secrets. Vault Admins and Box Admins are not able to directly view a secret or any previous versions of secrets. Even Vault Admins and Box Admins must be part of a Vault User Policy for boxes/secrets to gain access to secrets. To reiterate, Vault Admins do not have direct view access to secrets (they need to be a member of the relevant Vault User Policy to be able to successfully checkout and view secrets).
Box Admin Policy
The Box Admin Policy allows management and administration of boxes. Note that the Box Admin must be part of a relevant Vault User Policy to be able to checkout and view secrets, even on boxes that they can administer.