Announcing role-based access control

Introduction

‍

Controlling authorizations is at the center of a good internal developer platform implementation. An inability to create granular role-based access control isn’t feasible for any internal developer portal implementation and can even deter adoption of an enterprise-wide internal developer portal.

Role-based access control makes the developer experience better, since it shows what should be possible from a developer point of view and what actions can be taken, as well as the permitted views for the software catalog entities, based on access.

It also alleviates the concerns about exposing sensitive information stored in the internal developer platform. This is one of the reasons Backstage’s RBAC plugin is a paid feature.

When defining what we want to achieve in Port’s RBAC features, we wanted to ensure a no-code experience that is both flexible and simple. The ability to set access control simply and clearly is crucial, since a poor experience of implementing access control means policies and rules are less likely to be implemented and updated, exposing the company to possible vulnerabilities. The simpler it is to create granular access control rules, by role, the likelier it is these will be implemented and complied with.

‍

Our RBAC approach consists of the following:

Users & Team

Port inherits all teams and users from the SSO provider it integrates into.

On top of the derived structure, Port’s admin can create teams in Port, when a certain structure is required.

‍

Admins can perform any operation on the platform.

Moderators can perform any operation on a specific type of asset and related entities.  

Users have read-only permissions and/or permissions to execute certain actions.

‍

Setting the right read & write permissions

Internal developer portals contain a ton of information. We’ve written elsewhere about the sheer breadth of the information contained within the internal developer portal - about cloud assets, CI/CD pipelines, databases, K8s, microservices, secrets and more. While this breadth is important - only a comprehensive software catalog can support a good developer experience, it immediately raises the question of who should read what.

This is why our approach sets permissions at the user level, as well as the team level..

In some cases, the data in the software catalog is managed and modified from the UI by users (for example, changing the owner of a service). Port supports write permissions with an asset type and even specific property granularity level by team or user. 

‍

{{cta_3}}

Setting the right self-service action permissions

Self-service actions within the developer portal are core to its positive impact on the developer experience and to freeing devops from ticketops-led work. Yet these actions allow direct consumption of different resources, from spinning up temporary environments, asking for temporary permissions or scaffolding microservices. In this respect, we set to allow the definitions of policies that not only control who can perform certain self-service actions (or request manual approval) but also limit the amount of such actions (no more than x actions per month for a certain persona).

The granularity of Port’s permissions for self-service actions enables the admin to allow different user inputs by user, according to their proficiency. A good example of this is creating an S3 bucket. A full stack engineer will need to fill out 2 inputs, while a data engineer will probably need more advanced configuration capabilities and with 6 configurable inputs.

‍

Single sign-on and ownership-led permissions

Port integrates with identity provider tools, so that it is aware of the organization’s structure - teams, groups and users - ensuring that each can see what it owns and less of what it doesn’t own (but should be aware of)

‍

The importance of the audit log in the context of RBAC

Port has an audit log that stores every event that occurred within the developer portal, on the different blueprints or entities. It shows modifications, who invoked which developer self-service action, event status and more. It also shows any logs pertaining to how machines interacted with the information in the internal developer portal.