RBAC

Role-based access control systems are intended to restrict users from accessing certain features. You can control users’ access to the Tonomi Platform by defining roles, permissions and scope.

For example, RunInstanceWorkflow is a permission. We would like users to be able to execute instance workflows on any instance that belongs to a particular application. This can be done by specifying the following rule:

- RunInstanceWorkflow:
  - /applications/*

We can also restrict the permission to a particular instance:

- RunInstanceWorkflow:
  - /applications/<app id>/instances/<instance id>/workflows/*

Or, to a particular instance workflow (i.e. the RunInstanceWorkflow permission is scoped to an instance workflow or a command):

- RunInstanceWorkflow:
  - /applications/<app id>/instances/<instance id>/workflows/doSomething

It’s also possible to restrict the permission to several workflows at once by masking one or more parts of their names with the * wildcard symbol:

- RunInstanceWorkflow:
  - /applications/<app id>/instances/<instance id>/workflows/do*thing

This will permit access to workflows like “doSomething”, “do-any-thing” and “do_nothing” (as well as just “dothing”), but not to “undo-bad-thing”, “do_some_things” or “doThing” (wildcard patterns are case sensitive). The wildcards can be used in any part of workflow name, e.g., “*Something”, “doSome*”; or even in multiple parts simultaneuosly, e.g., “*Some*”.

Permission Rules

As described previously, every permission has an associated set of rules:

- RunInstanceWorkflow:
  - /applications/51b19654c1586a93639bd1c7/instances/*
- EnvironmentEdit:
  - /environments/*

In the example above, the permissions RunInstanceWorkflow and EnvironmentEdit and their URIs (i.e. scope) act as rules.

Note

A permission’s scope is the intersection of separate scopes (as defined by its URIs). The effective permission set is calculated as the union of all permissions for the user’s roles. In other words, URIs within individual permission entries are connected with AND, while different permission entries are connected with OR.

The following permission types exist in the Tonomi Platform:

  • Organization:
    • Organization Access
    • EditOrganization
    • CreateEnvironment
    • EditServices
    • CreateApplication
    • ManagePermission
  • Application:
    • CreateRevision
    • EditApplication
    • CreateInstance
  • Environment:
    • ViewEnvironment
    • EditEnvironment
    • EditInstance
    • CreateInstance
  • Revision:
    • EditRevision (currently limited to delete)
    • CreateInstance
  • Instance:
    • EditInstance
  • Workflow:
    • RunInstanceWorkflow

Note that any user who is allowed to “manage permissions” can create, edit and delete roles.

Create and Edit Instance

To create an instace (launch) user should have CreateInstance permission not only for the particular application, but also for all submodules (another appications) the application includes, if there are any.

To edit an instance (configure) user should have EditInstance permission only for the root instance not for submodules, also if reconfiguration will lead to creating new submodules - user should have CreateInstance permission for these submodule types (applications).

The reason why reconfiguration does not require EditInstance permission for submodules is that an instance can not be reconfigured in parts, but only entirely. In addition, subinstances are quite fluent entities, they can be destroyed or recreated after reconfiguration, it means there is no reason to specify their IDs in permission rules. To put it simple, EditInstance implies EditInstance permission for all subinstances.

To rename an instance user should have EditInstance permission only for the root instance.

Organization Access

Organization access is somewhat different from other permissions. It allows read-only access to any object that is not controlled by more specific permissions (e.g. environments) and is always present in any role. Any user who is not allowed to read organization data must be evicted.

Scope

To define scope properly for various object types, use the following URI format:

applications —  /applications/<id>
environments —  /environments/<id>
revisions —     /applications/<id>/revisions/<id>
instances —     /environments/<id>/instances/<id>
                /applications/<id>/instances/<id>
workflows —   any instance path + /workflows/<job name>

Note

Rather than specifying an id, you can use * to indicate a wildcard scope.

Special Roles

There are two special permanent roles created automatically for any organization: Administrator and User.

  • The Administrator role cannot be edited or deleted. This role is allowed to “manage permissions,” thus enabling users who are assigned the role to create more roles for specific actions. The organization’s creator is automatically assigned the Administrator role.
  • The Guest role can be edited, but not deleted. This role is assigned to all newly invited organization members. By default, only basic read-only access is enabled for this role.

Typical Tasks

Creating a Role

To create a role, you must have access to permissions management. Navigate to your organization page and click Roles. Then, select Create… and specify the role name. Click Edit to assign permissions to the newly created role.

../_images/createRoles.png

Assigning a Role to a User

On your organization page, click the Users tab, and then select the Assign Roles… button to highlight the required roles. You can remove all users’ roles; however, that would completely block his or her access to the system.

../_images/assignRoles.png

Inviting a New User to the Organization

Note

Since inviting a user means granting user access, the inviter must be a permissions manager.

To invite a user, select the drop-down menu in the top, right corner and click Invite colleagues…. Upon accepting the invitation, the user will be assigned to the Guest role.

../_images/inviteRole.png

Revoking Access

If a user is removed from a role or evicted from an organization, the user will lose access to corresponding objects. If the user was also subscribed to instance or environment notifications (using stars), then the notifications will stop being sent. Note that these subscriptions will not be restored if permissions are returned to the user.

Restricting Write Access to Certain Instances

To restrict write access to certain instances, put the instances under a restricted environment and ensure that only authorized users have the edit instances permission within it.

Hiding Sensitive Data inside Environment Policies

You can hide sensitive data inside Environment policies by allowing only authorized users to view a given environment. Note that other users will be still able to launch instances with the environment (provided they have the CreateInstance permission).

Examples

Full control over the organization

- EditOrganization:
  - /*
- CreateEnvironment:
  - /*
- CreateApplication:
  - /*
- ManagePermission:
  - /*
- CreateRevision:
  - /*
- EditApplication:
  - /*
- CreateInstance:
  - /*
- ViewEnvironment:
  - /*
- EditEnvironment:
  - /*
- EditInstance:
  - /*
- CreateInstance:
  - /*
- RunInstanceWorkflow:
  - /*

Full control over instances that belong to both a specific application and environment

Note that you can use YAML anchors to avoid duplication.

- RunInstanceWorkflow:
  - /applications/51b19654c1586a93639bd1c7/instances/*
  - /environments/51b19659c1586a93639bd1c8/instances/*
- EditInstance:
  - /applications/51b19654c1586a93639bd1c7/instances/*
  - /environments/51b19659c1586a93639bd1c8/instances/*
- CreateInstance:
  - /applications/51b19654c1586a93639bd1c7/
  - /environments/51b19659c1586a93639bd1c8/

Full control over instances that are either in a specific applicaion or environment

- RunInstanceWorkflow:
  - /applications/51b19654c1586a93639bd1c7/instances/*
- RunInstanceWorkflow:
  - /environments/51b19659c1586a93639bd1c8/instances/*
- EditInstance:
  - /applications/51b19654c1586a93639bd1c7/instances/*
- EditInstance:
  - /environments/51b19659c1586a93639bd1c8/instances/*
- CreateInstance:
   - /applications/51b19654c1586a93639bd1c7/
- CreateInstance:
   - /environments/51b19659c1586a93639bd1c8/