Access Control components
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 more granular policies:
Both of these components have finer-grained mechanisms in that incidents have type-based access control and settings have section-based access control.
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
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
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 IdentityGroupCreate
rule is mapped to theIdentityAdmin
roles. This means that a user mapped to theIdentityAdmin` can create new groups.
Root role and rule permit access to all APIs and resources in Blameless.