Access Control

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

For more information, please see the following:

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 can take the form of:

  • Denying or granting a principal access to a given secret
  • Allowing a principal to change their own password
  • Allowing a principal to create other principals

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

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 returns the principal details of the user, 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 returns 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" in the Getting Started with DevOps Secrets Safe guide.

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>

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

ssrun group remove-member

You can also execute the command promptless as follows:

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

You can supply principal resources for applications and users in a single command. A successful call to these commands results in no output from the CLI, while a failure outputs an error.

Delete Groups

Delete a group with the following command:

ssrun group delete

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

The deletion of a group also removes all authorization associations provided by the creation of the group.

Query Group Membership

The principal discovery mechanism, as described in the Getting Started with DevOps Secrets Safe guide, allows for querying both groups a particular principal belongs to and the principals belonging to a particular 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.

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 group's resource.

Manage Access Control by Group Association

In all authorization checks, an authenticated user or application provides 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 the Getting Started with DevOps Secrets Safe guide.

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 inherit the read permission on the secret at URI secret/testsecret:mytestsecret.

Conversely, a group can 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 overrides non-existing access, along with explicit allow access. This allows the administrator to build user groups that can be shielded from manipulating or reading sensitive existing resources in DevOps Secrets Safe.