Access Control

Before starting this section, ensure a new instance of DevOps Secrets Safe is running and the DSS CLI is configured to communicate with it. In addition, the system should be initialized, unsealed and a successful root authentication executed.

For more information about how to install the DevOps Secrets Safe CLI, please see Install the DevOps Secrets Safe CLI.

For more information about how the system should be initialized, unsealed, and successful root authentication, please see Getting Started with DevOps Secrets Safe.

The creation of users and applications introduces to the system the concept of principals (authorizable entities) that are subject to access control with relation to other resources in the system. This may be in the form of denying or granting a principal access to a given secret, change their own password, or the ability to create other principals.

This can be achieved as described in the Getting Started with DevOps Secrets Safe guide, or by utilizing groups.

Groups, as supported by DevOps Secrets Safe, provide the ability to grant or deny access to a resource by association. This reduces the overhead of multiple API calls to achieve bulk access control for multiple users of the system.

Create Users

Create a user with the following command:

$ ssrun user create

When prompted, provide the name to identify the user. This will return the principal details of the user, along with the URI.

Create Groups

Create a group with the following command:

$ ssrun group create

When prompted, provide a name to identify the group. This will return the principal details of the group, along with the URI.

Although a group is itself identified as a principal, groups may NOT be added to groups.

For more information about how to configure DevOps Secrets Safegroups with membership managed by external identity providers, please see Identity Provider Configuration.

Add or Remove Principals

Add principals by supplying a comma-separated list of principal resources when prompted:

$ ssrun group add-member

Optionally, you may enter the group name and principal resource list with keyword arguments:

$ ssrun group add-member --name <group_name> --principal_resources <principal_resources_list>

Similarily, to remove principals from a group, supply a comma-separated list of principal resources while prompted to the following command:

$ ssrun group remove-member

You may also execute the command promptless as follows:

$ ssrun group remove-member --name <group_name> --principal_resources <principal_resources_list>

You may supply principal resources for both applications and users in a single command. A successful call to these commands will result in no output from the CLI, while a failure will output the error.

Delete Groups

Delete a group with the following command:

$ ssrun group delete

When prompted, provide the principal name to identify the group. This will return the principal details of the group, along with the URI.

The deletion of a group will also remove all authorization associations provided by the creation of the grouping.

Query Group Membership

The principal discovery mechanism, as described in Getting Started with DevOps Secrets Safe, allows for the querying of both the groups a particular principal belongs to and the principals belonging to a particular group.

List Members of a Group

To list the members of a particular group, execute the following command:

$ ssrun group get --name <group_name> --verbose

Sample Output:

{
    "Uri": "/principal/internal/group/root",
    "ID": 2,
    "Name": "root",
    "Type": "group",
    "RemoteId": "c0d7cc51-83fb-4aa1-98fa-0a5b398f0132",
    "IdentityProvider": "internal",
    "IsRoot": true,
    "GroupMembers": [
        {
            "Uri": "/principal/internal/group/root/members",
            "Name": "members",
            "Members": [
                {
                    "Uri": "/principal/internal/user/root",
                    "ID": 1,
                    "Name": "root",
                    "Type": "user",
                    "RemoteId": "49d98c1d-29d4-450a-b14a-167cdb63b233",
                    "IdentityProvider": "internal",
                    "IsRoot": true
                }
            ]
        }
    ]
}

the creator of a group is given read access by default to the members resource. This does not need to be explicitly granted after group creation, except to other querying principals.

List Groups a Principal Belongs To

To list the groups a particular principal belongs to, execute the following command:

$ ssrun <user/application> get --name <principal_name> --verbose

Sample Output:

{
    "Uri": "/principal/internal/user/root",
    "ID": 1,
    "Name": "root",
    "Type": "user",
    "RemoteId": "49d98c1d-29d4-450a-b14a-167cdb63b233",
    "IdentityProvider": "internal",
    "IsRoot": true,
    "UserGroups": [
        {
            "Uri": "/principal/internal/user/root/groups",
            "Name": "groups",
            "Groups": [
                {
                    "Uri": "/principal/internal/group/root",
                    "ID": 2,
                    "Name": "root",
                    "Type": "group",
                    "RemoteId": "c0d7cc51-83fb-4aa1-98fa-0a5b398f0132",
                    "IdentityProvider": "internal",
                    "IsRoot": true
                }
            ]
        }
    ]
}

As with listing members, a user is given read access by default to its own groups resource.

Manage Access Control by Group Association

In all authorization checks, an authenticated user or application will provide a list of associated principals in which to determine access to an operation on a particular resource. Principals inherit all access permissions configured for groups they are members of. Denial-type rules take precedence over allow-type rules whenever access control entries conflict. Users and applications may exist in multiple groups, allowing for building comprehensive access control rules.

To configure authorization for a particular group (assume group URI principal/internal/group/<group_name>), execute an authorization creation command for a particular resource (assume secret URI secret/testsecret:mytestsecret), as described in Getting Started with DevOps Secrets Safe.

Allow Resource Access by Group

$ ssrun authorization create secret/testsecret:mytestsecret -p principal/internal/group/<group_name> -o read -a allow

If a given application or user belongs to group with group name <group_name>, they will inherit the read permission on the secret at URI secret/testsecret:mytestsecret.

Deny Resource Access by Group

Conversely, a group may be given an explicit denial to a resource, causing all group members to inherit the denial of access:

$ ssrun authorization create secret/testsecret:mytestsecret -p principal/internal/group/<group_name> -o read -a deny

This will override non existing access, along with explicit allow access. This allows the administrator to build user groups which can be shielded from manipulating or reading sensitive existing resources in DevOps Secrets Safe.