Administrators have the highest level of access, with organization management privileges that include creating, editing, and deleting users, projects, and roles.
Members have full access to Lightstep’s core features, which include viewing end-to-end traces and customizing dashboards, alerts, and Streams, but they do not have organization management privileges.
Viewers have read-only access to Lightstep’s monitoring capabilities – perfect for onboarding new users to Lightstep without disrupting existing workflows.
For more detailed information, visit our documentation pagedocumentation page and log in.
Role-based access control (RBAC) vs attribute-based access control (ABAC)
When architecting access control for Lightstep, we evaluated existing industry-wide access control standards. The two frameworks we focused on were (1) Role-based Access Control (RBAC) and (2) Attribute-based Access Control (ABAC).
With RBAC, roles are created and sets of permissions for resources are assigned to each role, and users are granted one or more roles to receive access to these resources. For example, you can have a user that has the role "Member" which maps to a set of permissions like creating alerts, editing dashboards, etc. On the other hand, ABAC gives access to resources via attribute-based policies. ABAC policies are rules that evaluate access based on four sets of attributes including: subject attributes, resource attributes, action attributes, and environment attributes. For example, you could have a policy like "all users in engineering in San Francisco should have edit access to all dashboards." Here, the subject attributes are
region:San Francisco, the action attribute is
action:edit, and the resource attribute is
We decided RBAC was a better fit for Lightstep for the following reasons. First, the primary advantage of ABAC is the ability to support extremely fine-grained permissioning, which is overkill in our product as we have no need to control access based on specific user resources (e.g. Only employees in the HR Department who are located in New York can access this dashboard). In addition, ABAC makes it extremely difficult, if not impossible, to determine the permissions available for a particular user. Whereas with RBAC, it’s much easier to audit the set of users that have access to a given permission, and the list of permissions granted to a particular user. There is also less overall complexity with RBAC, because roles can be described by their names and are easier to visualize than policies. Lastly, the performance of authorization queries is better with RBAC, assuming the number of roles remains reasonable, because we don’t have to look up data required for a specified policy from multiple sources.
The major risk we found with RBAC was potential "role explosion", which occurs when a huge number of roles are created to accomplish fine-grained authorization, resulting in slow lookup times and higher overall complexity. This risk is mitigated in our case, because currently our product only requires coarser-grained access control. In the end, the benefit of increased granularity provided by ABAC didn’t outweigh the cost of its increased complexity.
Mapping roles to permissions
Once we decided on using RBAC, the next question was how to map the list of available roles to authorization around our API access layer. One option was to assign API endpoints directly to each role, but this option was quickly ruled out because it would have left no room for us to extend our access control or API layer in the future. Tightly coupling the two means making changes to either would directly impact the other, a flexibility we did not want to lose.
We ended up going with a flexible permission model that introduces the concept of a "permission action", which is an abstract, logical grouping of API endpoints. These permission actions are first-class citizens in our software architecture – all authorization systems communicate using them. Each API endpoint belongs to a permission action, and each role is assigned one or more permission actions.
\Lightstep's role-based access control data model
The diagram above illustrates our RBAC data model where users have a many-to-many relationship with roles, and roles have a many-to-many relationship with permissions. Note that when performing an authorization check, we also confirm access to the API endpoint is permitted by checking the union of permission actions mapped to that user’s roles. This permissions model gives us the flexibility to support custom roles and extend our API layer in the future.
Try it out and share your feedback with us at firstname.lastname@example.org@lightstep.com.
Interested in joining our team? See our open positions herehere.
April 9, 2018
4 min read
About the authors
Daniela MiaoRead moreRead more
Katia BazziRead moreRead more
Explore more articles
Strengthening our commitment to the OpenTelemetry projectCarter Socha | Apr 20, 2023
Lightstep is the first company to natively provide customers with complete control of their telemetry pipeline which saves time and money, and provides the freedom to innovate at scale. By embracing OpenTelemetry support without vendor lock-in, Lightstep helps you make complex app development easier and faster.Learn moreLearn more
Transform ServiceNow workflows with Service Graph Connector for Observability - LightstepAndrew Gardner | Dec 20, 2022
The Service Graph Connector for Observability - Lightstep is the bridge between IT Operations and DevOps teams. When combined with ITOM Visibility, it provides organizations with a complete, end-to-end view of their entire cloud estate.Learn moreLearn more
Evolving our incident response strategyLightstep | Nov 2, 2022
Lightstep’s Incident Response offering will be sunset effective January 31, 2023. Current customers may continue to use the service until then. Lightstep Observability will not be affected.Learn moreLearn more
Lightstep sounds like a lovely idea
Monitoring and observability for the world’s most reliable systems