Conjur policy

Policy in Conjur enables you to define security rules in declarative files. These security rules describe which users and services have privileges to access workloads or get secrets such as passwords and API keys.

When Safes sync to Conjur, the policy tree structure for each Safe includes the following:

Delegation policy

For managing Conjur users, groups, hosts, and layers privileges:

<vault-name>/<lob-name>/<safe-name>/delegation

Consumer group

Has read and execute permissions to all of the Safe's secrets:

<vault-name>/<lob-name>/<safe-name>/delegation/consumers

Viewer group

Has read permissions to all of the Safe's secrets. Viewers can see the secrets and related data, but not the values.

<vault-name>/<lob-name>/<safe-name>/delegation/viewers

Grant role permissions on all secrets in a Safe

To grant role permissions on all secrets in a Safe, you must be a member of the <safe-name>-admins group.

Admins from admins-group can also grant permissions.

To grant permissions on all secrets in a Safe, add users, hosts, groups, and layers to the consumers group that has read and execute permissions on all Safe secrets.

Example of granting permissions on all secrets in a specific Safe

Bob is a Conjur user. He wants to grant Conjur Host /myapp/myhost read and execute permissions on all synced secrets in the secured_vault/serverapp_lob/db_accounts_safe Safe.

  1. Jane, the LOB admin, adds Bob to the db_accounts_safe-admins group, enabling him to grant permissions to /myapp/myhost on all secrets under the db_accounts_safe policy:

    1. Jane creates the following policy, bob.yaml, to grant Bob Safe admin privileges:

        
      - !grant
  role: !group db_accounts_safe-admins
  member: !user <path>/bob

    2. Jane loads bob.yaml to secured_vault/serverapp_lob:

        
      conjur policy load -b secured_vault/serverapp_lob -f bob.yaml

Grant role permissions on specific secrets in a Safe

To grant role permissions on specific secrets in a Safe, you must be a member of the <safe-name>-<lob-name>-admins group.

To grant permissions on specific secrets in a Safe:

Append the <vault-name>/<lob-name> policy using the Append to Policy REST API, granting permissions to users and hosts on the specific secrets .

 

Avoid using PUT (--replace) to update <vault-name>/<lob-name> policies. This may remove all synchronized secrets under the LOB, and would require manual steps to fix the synchronization.

Example of granting role permissions on a specific secret in a Safe

Bob is a Safe admin. Bob wants to grant a Conjur host, /myapp/myhost, read and execute permissions on the synced secret, secured_vault/serverapp_lob/db_accounts_safe/oracle_account/password.

Bob uses the db_accounts_safe policy to grant permissions to /myapp/myhost on this secret, as follows:

  1. Bob creates the myhost_delegation.yaml policy as follows:

      
    - !permit
role: !host myapp/myhost
  privileges: [read, execute]
  resources: [!variable oracle_account/password]

  2. Bob then loads the policy as follows:

      
    conjur policy load -b secured_vault/serverapp_lob/db_accounts_safe -f myhost_delegation.yaml

Jane is LOB admin. She wants to grant a Conjur host, /myapp/myhost, read and execute permissions on the synced secret, secured_vault/serverapp_lob/db_accounts_safe/oracle_account/password.

  1. Jane grants permissions to /myapp/myhost on a specific secret under the db_accounts_safe policy as follows:

    1. Jane creates the myhost_delegation.yaml policy as follows:

        
      - !permit
  role: !host /myapp/myhost
  privileges: [read, execute]
  resources: [!variable db_accounts_safe/oracle_account/password]

    2. Jane then loads the policy as follows:

        
      conjur policy load -b secured_vault/serverapp_lob -f myhost_delegation.yaml