The latest features and updates from Roadie.
🚨 Controlling your Catalog with Role-based Access Control (RBAC)
We’ve been working on this for a while and it is with some fanfare that we announce Role-based Access Control (RBAC) on Roadie. 🤝✨🙌
Transparency of information is at the heart of Roadie (and one of the key philosophical principles of Backstage), but there are often valid reasons for gating access to information and maintaining the principle of least privilege.
For example, let’s say you want to onboard Customer Service agents to your catalog so they can quickly find information about a service that may be experiencing some issues. You don’t necessarily want to give Customer Service folks the ability to execute a scaffolder run or browse through Tech Insights Scorecards: that’s just unnecessary and may even be confusing.
What you need in that situation is fine-grained control over your Roadie instance.
What is RBAC in Roadie?
- A new framework for access control in Roadie
- Every customer will have access to this new framework
- Some features are part of a paid add-on
And how does it work?
- Every part of Roadie is behind a Permission
- Roles are made up of sets of Permissions
- Users have Roles
- Admins can manage roles
- Admins can manage users
🎭 Role management
Several roles are available out of the box. They cover our existing access management setup as well as well as introduce some convenient shortcuts for new user groups that we’ve seen emerge recently:
- Admin
- Tech Insights Admin
- Maintainer
- Viewer
📚 Roles from a variety of sources, like your identity provider
The new permissions system will be allow you to send us roles from your identity provider as well as define them in the Roadie UI. This will mean the old GitHub Admin group is no longer required
Roles from all sources appear in the Role Management UI so you can understand where a user is inheriting a role from.
🆔 User management
You can then attach users to roles in the User Management UI and update the roles (and therefore permissions) that a user has access to on-the-fly.
As part of the switch-over to the new permissions system we run a background task to map the old roles system to the new one so there’s no switching cost for existing customers.
🛃 Custom permissions and roles
The out of the box roles will get you so far, but any organisations need or want a higher degree of control over who can see what in their Catalog, who has the right permissions to trigger Scaffolder actions, and which elements of Tech Insights are or aren’t displayed to certain users.
That’s where custom permissions policies and roles step in.
The ability to create new roles and attach fine-grained permissions are optional paid extras and will cover use cases like hiding services in the catalog or controlling who can run individual scaffolder templates. We can setup trials/start discussions if you’re interested.
What’s next for RBAC?
Individual entity permissions
At the moment, while we allow for a much higher degree of control over the catalog than before, we haven’t drilled down to the individual entity level to say You need to have permissions-to-view-X-component` to view X component’. That’s next.
That will mean you can:
- Control access to individual components or entities
- Control access to scaffolder templates and actions
- And create your own extremely specific permissions to target these entities
🙌 Backstage 1.26
We’ve now upgraded everyone to 1.26. This upgrade introduced some significant changes to the authentication system and lays the groundwork for the notification systems that lands fully in the next few versions.
🔌 Plugins & Integrations roundup
- Humanitec plugin: we now expose the Humanitec plugin, so you can view deployment information insider Roadie. Fun.
- Coder plugin: speaking of plugins, we also integrated the new Coder plugin. Tying neatly together Humanitec and Coder, Humanitec recently ran a webinar on how Coder thinks about integrating into Backstage which is worth checking out.
- AWS tag-based relationships: last but not least, on the topic of catalog data sources this time rather than plugins - we now ingest AWS tags as part of AWS automatic resource discovery. You can use tags to build relationships between newly ingested AWS resources and other entities in the catalog. Neat.