Managing Resources with Role Based Access Control

Overview

The Role Based Access Control (RBAC) service allows users to control access to Platform services and resources. Management of RBAC resources can only be performed by account/organization administrators. There are three primary resources RBAC uses to control access to services: Principals, Groups, and Roles. In order to give any Principal(user) access to an application resource, they must be added to a Group. The associated group must then be granted access by being bound to a Role or set of Roles. A Role defines access to specific application resources with a specific set of permissions.

Managing Principals

A Principal is an authenticated user that is a member of the Account. Principals can be searched and added to Groups in order to grant access to resources. RBAC itself does not perform any enforcement of that access, instead enforcement is left to the application logic. API endpoints involving Principals may only be accessed by Account Administrators.

Managing Groups

A Group is a collection of Principals used to grant access to a resource. A Principal can be a member of many Groups, and a Group can be associated with multiple Roles.

Permissions for Group API access

A user can only view (read) Groups. Administrators can view (read) and create/update (write) Groups.

Managing Roles

A Role defines a set of access control lists (ACLs). These ACLs define Permissions and contain Resource Definitions.

Permissions

A Permission is a three part object: application, resource type, operation

Application specifies the service or domain for the resource, for example:

- catalog
- approval
- cost-management

Resource type defines the resource to be controlled, for example:

- aws.account
- openshift.cluster

Operation defines the application logic action, for example:

- read
- write
- order

Note that in any of the above stanzas, * is taked to mean “all”.

Resource Definitions

Resource Definitions are a somewhat trickier aspect of our implementation of RBAC currently only used by the cost-management service.

In general, ALL roles should be created with a resourceDefinitions stanza of []. This is taken to mean “no additional filtering” and will generally result in the expected behavior.

In specific cases where the application logic has been written to handle them, however, resource access can be limited by specifing an attribute filter in the resourceDefinitions stanza as below.

Specifying a single resource with an attribute filter:

"resourceDefinitions": [
    {
        "attributeFilter": {
            "key": "uuid",
            "operation": "equal",
            "value": "39c8cecd-e595-46fb-8908-13365d59d5e8"
        }
    }
]

While you can specify resources individually you can also specify a multiple resource with an attribute filter as follows:

"resourceDefinitions": [
    {
        "attributeFilter": {
            "key": "uuid",
            "operation": "in",
            "value": "39c8cecd-e595-46fb-8908-13365d59d5e8,9928e33b-e28f-4e82-b996-12e222f08098"
        }
    }
]

Permissions for Role API access

Only an account administrator can view (read) roles or create/update (write) roles. Non-administrator can view (read) roles within their scope with scope specified in the API call -?scope=principal.