Grant permissions on secrets

Policy in Conjur Cloud 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 Cloud, the policy tree structure for each Safe includes the following:

Delegation policy

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

data/vault/<safe-name>/delegation

Consumer group

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

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

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 Conjur_Cloud_Admins 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@example.com is a user in Conjur Cloud and a member of the Conjur_Cloud_Users group. He wants to grant the host, /myapp/myhost, read and execute permissions on the db_accounts_safe Safe. For this, bob@example.com needs permissions to provide privileges for the host. Any user from the Conjur_Cloud_Admins group can grant these permissions.

  1. The tenant admin user, alice@example.com, creates the host under the data branch:

    1. alice@example.com creates the following policy, create_host.yaml, which creates the /myapp/myhost host that is owned by bob@example.com:

        
      - !policy 
  id: myapp
  body:
    - !host
      id: myhost
      annotations:
        authn/api-key: true
  owner: !user /bob@example.com

    2. alice@example.com loads create_host.yaml to data:

        
      $ conjur policy load -b data -f create_host.yaml

  2. alice@example.com adds bob@example.com to the db_accounts_safe-admins group:

    1. alice@example.com creates the following policy, grant_privileges.yaml, to grant bob@example.com Safe admin privileges:

        
      - !grant
  role: !group db_accounts_safe-admins
  member: !user /bob@example.com

    2. alice@example.com loads grant_privileges.yaml to data/vault:

        
      $ conjur policy load -b data/vault -f grant_privileges.yaml

  3. bob@example.com, now a Safe admin, adds the /myapp/myhosthost to the data/vault/db_accounts_safe/delegation/consumers group to grant it read and execute permissions on all secrets in the db_accounts_safe Safe.

    1. bob@example.com creates the following policy, grant_permissions.yaml, which adds myapp/myhost to the db_accounts_safe/delegation/consumers group:

        
      - !grant
  role: !group delegation/consumers
  member: !host /data/myapp/myhost

    2. bob@example.com loads grant_permissions.yaml to data/vault/db_accounts_safe:

        
      $ conjur policy load -b data/vault/db_accounts_safe -f grant_permissions.yaml

    The host /myapp/myhost now has permissions on all secrets under db_accounts_safe.

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>-admins group.

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

Following the previous example, bob@example.com is a Safe admin and the owner of the data/myapp policy. bob@example.com wants to grant the host, /myapp/dbhost, read and execute permissions on the synced secret, db_accounts_safe/oracle_account/password.

  1. bob@example.com uses the db_accounts_safe policy to grant permissions to /myapp/dbhost on this secret:

    1. bob@example.com creates the following policy, create_dbhost.yaml, which creates a new host:

        
      - !host 
  id: dbhost
  annotations:
    authn/api-key: true

    2. bob@example.com loads create_dbhost.yaml to data/myapp as follows:

        
      $ conjur policy load -b data/myapp -f create_host.yaml

  2. bob@example.com creates permission policy, dbhost_permission.yaml, for dbhost:

      
    - !permit 

  role: !host /data/myapp/dbhost
  privileges: [read, execute]
  resources: [!variable oracle_account/password]

    bob@example.com loads the policy as follows:

      
    conjur policy load -b data/vault/db_accounts_safe -f dbhost_permision.yaml

The host /myapp/dbhost now has permissions on the secret oracle_account/password that's under db_accounts_safe.