Identity & Access Management

Blameless providers users with the ability manage identities and access control via users, groups and roles.

Getting Started

This guide will walk users through setting up roles and groups in Identity Access Management in the Blameless Platform

Users

The user object is automatically created inside Blameless once we connect to your identity provider such as Okta.

Roles

Every product area within Blameless has specific roles associated with it.

Groups

Groups can be created inside Blameless. These groups can then be used to associate permissions for Blameless resources such as incidents and postmortems and a collection of users. The admin group is available by default.

Create a Group

Navigate to the settings page and click on the Identity Management section. Then click on "Add Group".

IAM - Create group

You will be able to name the group to whatever your preference is and attach an email address to that group.

Associate Users with the Group

Clicking on the settings for the group (3 dots lined vertically) you will be able to assign users and roles to the group you just created. Click on Assign/Unassign users and you will be able to select which users to add to the group.

IAM - Assign UsersIAM - Assign Users Modal

Associate Roles with the Group

To associate roles to the group you created, click on the settings for that group. Select Assign/Unassign roles.

IAM - Assign RolesIAM - Assign Roles Modal

You will be able to select which roles and permissions the specific group has. Clicking on the roles you want for that group and clicking on Assign will save those settings.

After assigning users and roles to a group, you can view the group's associations by clicking on setting for the group and selecting Show Associations.

IAM - Show Group Associations

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 sub-component. API access control will permit or restrict access at the REST API layer.

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.

Sub-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. As of this writing, there are two components with even finer-grained policies: incidents and settings. Both of these components have finer-grained mechanisms: incidents have type-based access control and settings have section-based access control.

Incident Type

Blameless allows customers to create custom incident types. For example, the security team may want to create incidents specific to security events and only permit access to the security team. When creating the new type, a new role is created with rules specific to reading, updating and creating that specific incident type. Only users with that role will be permitted access to that incident type.

When a new incident type is created, an associated Admin role is created for that type: <Type>IncidentAdmin. Type-specific rules similar to the rules mapped to IncidentAdmin will be created. This means that all users performing actions on incidents of the custom type must have the <Type>IncidentAdmin role.

Settings Sections

Blameless settings cover a few scopes (global, user, org) and sections (integrations, incident, etc.). There are cases where a user requires access to an org-level setting, such as incident for creating incidents, but should never have access to more senisitve settings, such as integration credentials (e.g. Jira password). Separating access by section gives customers the ability to ensure users can effectively use the platform, without compromising security.

Rules to Roles Mapping

Here we provide 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.

The format of the following list is as follows. Each list item contains an identifier for a rule in Blameless' RBAC system, formatted as Component[Subcomponent][Section|Type]Action.

For example, IncidentTaskReader is the rule that allows reading of incident tasks and SettingsSensitiveRead is the rule that allows reading of sensitive settings, such as passwords.

Each list item contains a nested list that corresponds to the user-visible roles this rule is mapped to. For example, the IdentityGroupCreaterule is mapped to theIdentityAdminandIdentityWriterroles. This means that a user mapped to theIdentityAdmin` can create new groups.

Finally, the Root role and rule permit access to all APIs and resources in Blameless.

RuleAuditlogReaderCommsLeadAdminDashboardAdminDashboardReaderDashboardWriterIdentityAdminIdentityReaderIdentityWriterIncidentAdminIncidentReaderIncidentWriterRootSettingAdminSettingReaderSettingWriterSloAdminSloReaderSloWriter
IncidentTaskDeleteXX
IncidentEventUpdateXXX
IncidentCommunicationExecuteXXX
IncidentCommunicationCreateXXXX
IncidentMemberDeleteXX
IncidentPostmortemCreateXXX
IncidentActionDeleteXX
IncidentRoleReadXXX
IncidentTaskReadXXX
IncidentTaskCreateXXX
IncidentPostmortemReadXXX
IncidentTaskUpdateXXX
IncidentActionReadXXX
IncidentEventCreateXXX
IncidentPostmortemUpdateXXX
IncidentCommunicationReadXXXX
IncidentCreateXXX
IncidentUpdateXXX
IncidentCommunicationUpdateXXXX
IncidentEventDeleteXX
IncidentActionCreateXXX
IncidentReadXXX
IncidentEventReadXXX
IncidentActionUpdateXXX
IncidentTicketCreateXXX
CommentsCreateXXX
CommentsInfoUpdateXXXX
CommentsUpdateXXX
CommentsDeleteXX
CommentsReadXXXX
IdentityUserReadXXXXXXXXXX
IdentityOrgReadXXXXXXXXXX
SettingsOrgIncidentReadXXXXXX
SettingsOrgPostmortemReadXXXXXX
SettingsTimezoneReadXXXXXX
UserInfoReadXXX
PrivateChannelReadXXX
DashboardDeleteXX
DashboardTemplateReadXXX
DashboardChartReadXXX
DashboardReadXXX
DashboardCreateXXX
DashboardTitleUpdateXXX
DashboardTitleDeleteXX
DashboardTitleCreateXXX
DashboardUpdateXXX
TopicReadXXXX
TopicExecuteXXXX
TopicSegmentReadXXXX
FactReadXXXX
SettingUpdateXXX
SettingReadXXX
SettingsLocaleReadXXX
SettingsLocaleUpdateXXX
SettingsOrgBotReadXXX
SettingsOrgBotUpdateXXX
SettingsOrgChatbotReadXXX
SettingsOrgChatbotUpdateXXX
SettingsOrgCommentsReadXXX
SettingsOrgCommentsUpdateXXX
SettingsOrgIncidentUpdateXXX
SettingsOrgIntegrationReadXX
SettingsOrgIntegrationUpdateXX
SettingsOrgNameReadXXX
SettingsOrgNameUpdateXXX
SettingsOrgPostmortemUpdateXXX
SettingsOrgSecurityReadXX
SettingsOrgSecurityUpdateXX
SettingsOrgWebhooksReadXXX
SettingsOrgWebhooksUpdateXXX
SettingsTimezoneUpdateXXX
SettingsSensitiveReadXX
SettingsSensitiveUpdateXX
SloReadXXX
SloExecuteXX
SloCreateXXX
IdentityReadXXX
IdentityRoleCreateXXX
IdentityRoleUpdateXXX
IdentityGroupCreateXXX
IdentityUserCreateXXX
IdentityRuleCreateXXX
IdentityOrgCreateXXX
IdentityGroupDeleteXX
IdentityCreateXXX
IdentityUserDeleteXX
IdentityUpdateXXX
IdentityGroupUserCreateXXX
IdentityUserUpdateXXX
IdentityGroupUpdateXXX
IdentityOrgUpdateXXX
AuditlogReadXX

API Access Control

Each API endpoint can have at most one rule associated with it. All users with matching rules are permitted access to the endpoint. Any endpoint without a rule (i.e. None) are accessible by all authenticated users.

For example, the health does not have access control, while GET /api/v1/incidents requires the IncidentRead rule.

Slack Bot Access Control

Each Slack command can have at most one rule associated with it. All users with matching rules are permitted access to the endpoint. Any endpoint without a rule (i.e. None) are accessible by all authenticated users.