Role-based Access Control

Blameless ships with role-based access control policies that allow organizations to restrict access to certain APIs and resources.

Role-based Access Control (RBAC)

Blameless ships with role-based access control policies that allow organizations to restrict access to certain APIs and resources. Each role is associated with one or more rules that dictate access. An example rule might be "incident read" (can read incidents) or "incident postmortem read" (can read postmortems). Rules are grouped into pre-defined roles that are mapped to user groups. Users that are granted access to the proper identity rules have the ability to add users to groups and roles to groups, providing fine-graned access to users. Note that all roles are pre-defined or generated by Blameless. There are cases where custom roles can be created, specifically when creating new incident types. Currently, outside of custom incidents, roles are only generated by Blameless engineering.

Here we enumerate the existing rules, rule-to-role mapping and the rules required to access specific resources in Blameless.

As of today there are two types of access control: API and Blameless component. API access control will permit or restrict access at the REST API layer.

Access Control

Each role is associated with one or more rules that dictate access. An example rule might be "incident read" (can read incidents) or "incident postmortem read" (can read postmortems).

Rules are grouped into pre-defined roles that are mapped to user groups. Users that are granted access to the proper identity rules have the ability to add users to groups and roles to groups, providing fine-grained access to users. Note that all roles are pre-defined or generated by Blameless. There are cases where custom roles can be created, specifically when creating new incident types. Currently though, outside of custom incidents, roles are only generated by Blameless Engineering.

Here we enumerate the existing rules, rule-to-role mapping, the rules required to access specific resources in Blameless , and permissions affecting the API and Slack components.

As of today there are two types of access control:

  • API / Slack Bot

  • Sub-component

    note

    API access control will permit or restrict access at the REST API layer. Also, there are Slack Bot-specific API endpoints that we call out as part of the greater API family associated with Blameless. They are identified and samples provided in the Slack Bot Access Control section.

Rules for Role Mapping

Blameless provides the mapping of the rules used to permit/restrict access to the customer-visible roles mapped to users/groups. This will allow users to reason about what roles to map to specific users based on the needs of each user group. Refer to the Roles Mapping List for more information.

Permissions required for API and Slack

Permissions also play a role, along with Roles and Rules.

API Access Control

Each API endpoint has an authentication and authorization hook that ensures the caller is both authenticated and authorized to call the endpoint. The authorization hook is associated with a (verb, resource,rule) tuple. If the user's identity has a matching rule, then calling the (verb, resource) API is granted. Refer to the API Access Control Examples list for more information.

Slack Bot Access Control

Each Slack Bot specific command can have at most one rule associated with it. Any user with matching rules can access the API. Any endpont with a rule (tagged as None) can be accessed by all.

Refer to the Slackbot Access Control List Examples for more information.

Blameless Component Access Control

Blameless consists of the following components:

  • Incidents
  • Postmortems
  • Dashboards
  • Settings
  • Identity
  • Comments
  • SLO

The API access control mechanisms will permit access at the component level (e.g., you either have access to the dashboard component or you don't) and sub-component level.

Incidents and Settings

As of this writing, there are two components with an even precisely definable policies:

  • Incidents
  • Settings

Both of these components have precise mechanisms: incidents have type-based access control and settings have section-based access control.

Refer to the Subcomponent Access Control List.