Close
logodocs

Access Rules and Multi-Role Membership Beta

The content on this page is a collection of information about the open beta version of strongDM's Admin UI.

The Access Rules and Multi-Role Membership beta provides a new and improved access system that changes the way access to resources is granted in strongDM. This beta is different than previous betas in a few ways. This document provides information about the changes that the beta brings to strongDM and what you can expect when your organization transitions to the new access system.

The following summary describes the main changes:

  • Once your organization moves to the new access system, there is no return path. Our Support and Engineering teams will be fully available to address any issues you may encounter and to assist with the transition.
  • You will no longer be able to grant access directly to Users, except for Temporary Access. From now on, permanent access is only granted through Role Membership, via the Static and Dynamic Access Rules that have been defined for that Role.
  • Users with permission grants that aren't in a Role will become members of a newly created Role named after them. This Role will contain their pre-existing access in the form of a Static Access Rule.
  • Any custom scripting in your applications that interacts with Composite Roles will no longer work and will return an error.
  • Attaching Users to "No Role" as a way of removing them from a Role will no longer work. Instead use the new unassign and unassign-all commands.
  • As part of this upgrade, all of your permission grants will be instantly recreated. When using audit commands to examine permissions you will see records with a GrantedAt date matching the date of the migration — these are neither changed nor new permissions, but rather the same set of permissions that existed in your organization just before the upgrade.
  • All of your existing Roles will remain the same, and existing access provided by those Roles will be converted to Static Access Rules (see section Static Access Rules for more information).
  • All of your existing Composite Roles will be removed. Members of Composite Roles will become members of each of the Roles that were previously part of the Composite Role.
  • The standard limit on the number of Roles a User can be a member of is 20.
  • Port Overrides is no longer available to turn off, as it is default behavior.

Terms and Concepts

Users

Users List
Users List

Users can either be traditional Users or Service Accounts. What a User can see or do in the Admin UI, via the CLI, or through the API is determined by the permission level set for that User.

User Details View
User Details View

The types of Users are:

  • Users: A User in strongDM represents an individual member of your organization who can log in to strongDM. In the Admin UI's User management area, each User either will be granted permissions for individual specific resources, or be added to a role which will determine what resources the User can access.
  • Service Accounts: Service Accounts are a type of User that allows for programmatic access to strongDM resources. See the Service Accounts page for more details.

Special indicators

In the Admin UI, when Users are listed, some of them may have special indicators next to their names to show that they are different in some way. In addition to those already discussed in the User Management documentation, the beta adds the sdm badge. In an organization with SCIM Provisioning activated, Users that have an sdm badge next to their name are still managed fully through strongDM rather than the provider.

Roles

Roles List
Roles List

Roles are slightly different than before. Previously, Roles were collections of manually set permissions that were applied to Users, helping to uniformly manage large sets of Users and their access to resources — particularly when repeated access needs and limitations were present. Now, Roles have evolved to become collections of Access Rules giving members permissions to manage or access various parts of your organization's strongDM User and resources. Each User can now be a part of up to 20 Roles.

Role Details View
Role Details View

Composite Roles will no longer be necessary, as a user may belong to as many Roles as required. Currently, you can only add Roles to Users from the Users page, not from the Roles page. This may change in the future.

Tags

Key-value pair tags can now be added to your resources from the Admin UI. You may choose from existing tags that you have already used, or you can add new tags. Once resources are tagged as desired, you may then use those tags to define Access Rules (as discussed in the sections that follow). Please see the existing Tags page for more information about how tags work in strongDM.

Access Rules Editor

Access Rules are now the building blocks of Roles. You can add, edit, or delete Access Rules within a Role. To edit an Access Rule, click edit. To delete an Access Rule, click edit and once the Edit view is open, click Delete Access Rule.

Each Role can comprise up to 10 Access Rules.

The Access Rule editor can create both Static Access Rules and Dynamic Access Rules.

Static Access Rules

Static Access Rules are the method by which you can assign access to specific resource(s) to a Role, one at a time from a list of checkboxes. If you are migrating from the old Roles model, all of your current Roles will be made up of Static Access Rules, as this mimics the legacy process of creating Roles one permission at a time.

Dynamic Access Rules

Dynamic Access Rules provide the tool set to dynamically assign resource access to members of the Role. Each Dynamic Access Rule is made up of two properties:

  1. Resource type. You can choose a specific type of resource, such as a MySQL DBs or EKS Clusters, or you can choose All resource types.

  2. Resource tags. Tags are key-value pairs assigned to resources.

A Dynamic Access Rule will grant access to all resources that meet all of the criteria specified in its properties. For example, specifying one database type and two tags will grant access only to resources that are of that database type and have both of those tags.

The Access Rule editor will let you know if there are no resources that currently match your criteria. If there are matching resources, it will indicate how many.

CLI Commands for Roles

Assign Users to a Role

$ ./sdm admin users assign --help
NAME:
sdm admin users assign - attach a set of users to a role
USAGE:
sdm admin users assign [command options] <role-name> <user-email-1> [user-email-2 user-email-n...]
OPTIONS:
--template, -t display a JSON template
--file value, -f value load role assignments from JSON file
--stdin, -i load from stdin
--filter value filter e.g. 'field:name tag:key=value ...'
--filter-json value path to JSON based filter

Unassign Users from a Role

$ ./sdm admin users unassign --help
NAME:
sdm admin users unassign - detach a set of users from a role
USAGE:
sdm admin users unassign [command options] <role-name> <user-email-1> [user-email-2 user-email-n...]
OPTIONS:
--template, -t display a JSON template
--file value, -f value load role assignments from JSON file
--stdin, -i load from stdin
--filter value filter e.g. 'field:name tag:key=value ...'
--filter-json value path to JSON based filter

Unassign Users from all Roles

$ ./sdm admin users unassign-all --help
NAME:
sdm admin users unassign-all - detach a set of users from all roles
USAGE:
sdm admin users unassign-all [command options] <user-email-1> [user-email-2 user-email-n...]
OPTIONS:
--template, -t display a JSON template
--file value, -f value load service accounts from JSON file
--stdin, -i load from stdin
--filter value filter e.g. 'field:name tag:key=value ...'
--filter-json value path to JSON based filter

Assign Service Users to a Role

$ ./admin services assign --help
NAME:
sdm admin services assign - attach a set of service accounts to a role
USAGE:
sdm admin services assign [command options] <role-name> <service-name-1> [service-name-2 service-name-n...]
OPTIONS:
--template, -t display a JSON template
--file value, -f value load role assignments from JSON file
--stdin, -i load from stdin
--filter value filter e.g. 'field:name tag:key=value ...'
--filter-json value path to JSON based filter

Unassign Service Users from a Role

$ ./sdm admin services unassign --help
NAME:
sdm admin services unassign - detach a set of service accounts from a role
USAGE:
sdm admin services unassign [command options] <role-name> <service-name-1> [service-name-2 service-name-n...]
OPTIONS:
--template, -t display a JSON template
--file value, -f value load role assignments from JSON file
--stdin, -i load from stdin
--filter value filter e.g. 'field:name tag:key=value ...'
--filter-json value path to JSON based filter

Unassign Service Users from all Roles

$ ./sdm admin services unassign-all --help
NAME:
sdm admin services unassign-all - detach a set of service users from all roles
USAGE:
sdm admin services unassign-all [command options] <service-name-1> [service-name-2 service-name-n...]
OPTIONS:
--template, -t display a JSON template
--file value, -f value load service accounts from JSON file
--stdin, -i load from stdin
--filter value filter e.g. 'field:name tag:key=value ...'
--filter-json value path to JSON based filter

The --template option produces example --file or --stdin input. An example --filter-json file:

[
{
"lastName":"S1"
}
]

Examples of the Structure of Access Rules

This section shows some examples of how different kinds of Access Rules are structured. You can create and edit Access Rules using structures such as these via the CLI, SDKs, and Terraform.

Structure of a Static Access Rule

{
"ids": [
"rs-0c3b76e560f5f37b",
"rs-22904ced60ac13ec",
"rs-25b92097609bed25",
"rs-2d396d0260a810cb",
"rs-2f1d8408609bf95a",
"rs-74b6183d60f5e06b"
]
}

Structure of a Dynamic Access Rule with one resource type

This example is based on a specific resource type.

{
"type": "aurora-mysql"
}

Structure of a Dynamic Access Rule with one resource type and tags

This example is based on a specific resource type plus multiple tags.

{
"type": "aurora-mysql",
"tags": {
"auth": "ss",
"env": "prod"
}
}

Structure of a Dynamic Access Rule with one tag

This example is based on a single specific tag.

{
"tags": {
"env": "test"
}
}

Structure of a Dynamic Access Rule with multiple tags

This example is based on multiple tags.

{
"tags": {
"auth": "sdm",
"env": "dev"
}
}

A Go SDK example of managing Users and Roles

func ExampleMultiRoleChanges()
var client *sdm.Client
var ctx context.Context
user1, _ := client.Accounts().Create(ctx, &sdm.User{
FirstName: "MyUser",
LastName: "Example",
Email: "example+user@strongdm.com",
})
role1, _ := client.Roles().Create(ctx, &sdm.Role{
Name: "MyRole",
})
role2, _ := client.Roles().Create(ctx, &sdm.Role{
Name: "MyRole2",
})
// Post Multi-role, composite roles do not exist, and this will fail
_, err := client.Roles().Create(ctx, &sdm.Role{
Name: "MyCompositeRole",
Composite: true,
})
fmt.Println(err)
// before: <nil>
// now: a populated error
// Instead, multiple account attachments for the same user are now allowed
client.AccountAttachments().Create(ctx, &sdm.AccountAttachment{
AccountID: user1.Account.GetID(),
RoleID: role1.Role.ID,
})
client.AccountAttachments().Create(ctx, &sdm.AccountAttachment{
AccountID: user1.Account.GetID(),
RoleID: role2.Role.ID,
})
iterator, _ := client.AccountAttachments().List(ctx, "accountID:?", user1.Account.GetID())
attachments := []*sdm.AccountAttachment{}
for iterator.Next() {
attachments = append(attachments, iterator.Value())
}
fmt.Println(attachments)
// before: [0xc000f5ad50]
// now: [0xc000f5ad50, 0xc000f5ad55]
}

Examples of Access Rule Use in SDKs and Terraform

Access Rules in Terraform

How do I create a single Access Rule in a Role?

resource "sdm_role" "people" {
name = "People"
access_rules = <<EOF
[
{
"type": "redis"
"tags": { "foo": "bar" }
}
]
EOF
}

How do I create multiple Access Rules in a Role?

resource "sdm_role" "people" {
name = "People"
access_rules = <<EOF
[
{
"ids": [ "${sdm_resource.ds1.id}" ]
},
{
"type": "redis"
},
{
"type": "redis"
"tags": { "foo": "bar" }
}
]
EOF
}

How do I remove all Access Rules from a Role?

resource "sdm_role" "people" {
name = "People"
access_rules = "[]"
}

Access Rules in the Python SDK

How do I create a single Access Rule in a Role?

role.access_rules = """
[
{
"type": "redis"
"tags": { "foo": "bar" }
}
]
"""
_ = client.roles.update(role)

How do I create multiple Access Rules in a Role?

role.access_rules = """
[
{
"ids": [ "{0}" ]
},
{
"type": "redis"
},
{
"type": "redis"
"tags": { "foo": "bar" }
}
]
""".format(resource.id)
_ = client.roles.update(role)

How do I remove all Access Rules from a Role?

role.access_rules = "[]"
_ = client.roles.update(role)
Admin UI Guide — Previous
Access
Next — Admin UI Guide
Create Admin Tokens