Unlock New RBAC Powers: Introducing the 'Team Member' Role in OpsLevel

What is the Team Member Role?

The Team Member role in OpsLevel merges ownership information from the catalog into the authorization system. Here's how it works:

• On a Team That Owns a Service? You can edit it.
• Not on a Team That Owns a Service? You can’t edit it.

This authorization scheme respects the recursive nature of teams.  If you’re a member of a parent team, you can edit services owned by any child team. For example, if you're a member of the Platform Team, which is a parent team to the API Team, you are able to modify services owned by both the Platform and API teams. However, if you are only a member of the API Team, you can't make changes to services owned by the Platform Team.

This distinction addresses a common Admin concern: preventing "drive-by" edits to services. With the Team Member role, only those who own a service can make changes, ensuring accountability and reducing the risk of unintended (or malicious) modifications.

‍

Why is Robust RBAC Important in an IDP?

Role-Based Access Control (RBAC) is essential for maintaining security and operational efficiency. By restricting access based on roles, RBAC ensures that only authorized users can perform specific actions, thereby protecting sensitive information and ensuring compliance with internal and external policies. Additionally, clear role definitions streamline workflows by assigning the right level of access to the appropriate people, reducing bottlenecks and enhancing overall productivity.

According to Gartner, "By 2025, 99% of cloud security failures will be the customer’s fault." Implementing strong RBAC policies is a proactive step in reducing this risk, ensuring that permissions are granted appropriately and actions are traceable.

OpsLevel vs. Competitors

OpsLevel's new Team Member role provides granular control over who can edit services, something our many of our competitors simply don't offer - instead only focusing on broad, admin-level controls. Scoping a team member's activity to only their team's services is crucial for maintaining order and security within large, complex engineering organizations.

Use Cases for the Team Member Role

1. Service Ownership and Accountability: Teams that own services can edit them, ensuring that only those responsible for a service can make changes, fostering accountability.
2. Cross-Team Collaboration: Developers from other teams can view services but cannot make changes, preventing accidental modifications and maintaining the integrity of the system.
3. Streamlined Change Processes: With clear roles and permissions, code changes and fixes, as there’s no confusion over who has the authority to make changes.

Implementing the Team Member Role

Implementing the Team Member role is straightforward. By default, users provisioned through SCIM or SSO will receive the role of Team Member. Admins can modify the default role for their account in the Roles & Permissions section of the OpsLevel platform.

Enhancing our robust RBAC capabilities

The new Team Member role is an added bonus to our existing roles:

• Admin: Can modify everything within the portal
• Standards Admin: Can create Scorecards, Rubrics, Checks, and Campaigns
• User:  Can modify all service and team metadata
• Team Member: Can only modify the services they own

For more information on setting up and managing roles, please refer to our documentation.

The introduction of the Team Member role is a significant step forward in enhancing the functionality and security of OpsLevel’s IDP. By providing more precise control over who can make changes to services, we’re helping engineering teams work more efficiently and securely.

Ready to see the Team Member role in action? Book a call with our team to get your hands on OpsLevel today.

‍