Role Based Access Control
· Kubecost, an IBM Company ·
Saas · UI · UX · Product Management
Overview
Many organizations do not want to share the full picture of their Cloud or Kubernetes spend with their entire organization. Rather, they’d prefer to limit the views of some teams to the resources and spending which is relevant. Previously, users were able to limit access to some extent via helm configuration. This left a gap in what was attainable as well as presented a large complication for users. To remedy this issue, we focused on delivering functional RBAC (role-based access control) capabilities via our UI.
Product
Product Management
The need for a comprehensive RBAC solution drove us to strive for a quick launch in the upcoming release cycle. Configuring RBAC solutions via helm was proving cumbersome to our users. As such, we got started with a light weight PRD. The RBAC PRD outlined the requirements for a RBAC feature that was complimentary to our features and how users would employ it. I recruited our Product Manager and Front End Engineer to identify what this RBAC process should encompass and what that looks like for our users. We also to into considerations users with predefined permissions configured with helm. Giving them the ability to via these permission would serve the user and further improve permission control from all aspects. With this, we were able to create a PRD to use as an outline, keep us in scope and encourage transparency for the progression of the project.
Check out an excerpt from the RBAC PRD. We used this to identify key requirements, eliminate confusion around how the feature will behave and to address outstanding questions regarding the user experience. This document was also used to keep track of design & engineering proposals.
UX
Developing the User Experience
There was a lot to tackle with how users would select specific pages, features and aggregations for allowed access. Additionally, there was the complication of identifying what qualifies as a role for Kubecost and what all does a team encompass.
We identified a role as simply hosting access to a set of pages, and if needed, specific filters for those pages.
We identified a team as a person or group of people allowed access to a defined role.
Having hashed that out, I jumped into creating a user experience flow.
I used the PRD developed to design a ux outline as my foundation for the mocked user experience. As this project ran on a tight timeline, I bypassed low fidelity mocks and used the outline in lieu.
UX
Designs: Roles
After sorting through the technicalities, I was able to design a simplistic approach to our RBAC feature. This approach took how users were utilizing this via helm and translated it to our UI. I focused on simplicity and clear paths to ease the frustration of access management.
Users are clearly guided through the steps needed to create a desired role. They have the ability to sort pages via its parent category ie. Monitoring, Govern, Savings etc as well as filter the selected pages to a specific parameter. Additionally, users have the ability to select an entire category which auto selects all child pages. Added filters are populated under the filter component as “chips” which can be deleted by selecting the “x” within the chip.
Once saved, the new role is populated as the first row in the Roles table.
On hover, users are presented options to duplicate, edit or delete created roles. Duplicated roles are published as “Copy of “X”.
When selecting a row, users are able to “Inspect” its description and set permissions. Users can also choose to edit the role at this screen as well.
Selecting edit from the option listed in the row, takes the user directly to the creation modal which will be populated with the set permissions for the selected role.
UX
Designs: Teams
The Teams section remained consistent in design and layout with a few changes to account for how the API handled information regarding Teams. As an example, Teams cannot be duplicated, they can only be edited or deleted as per API constraints.
It was also important to convey information to users belonging to multiple teams. Having belonged to multiple teams, a user will receive the maximum permissions granted to them.
Ex. John belongs to Perm_1 and Perm_4. Perm_1 does not have access to Allocations, however Perm_4 does. As a result, John will have access to Allocations.
Users follow a consistent ux that guides through Team creation. It was also important to leave a link to docs explaining what a claim is and how it impacts team creation. Users are then able to search for roles which populates auto-complete results.
As with Roles, users are able to Inspect a team by clicking on its row.
UX
Designs: Helm
It was important to provide a way for users to view previous permissions made via helm. To accomplish this, helm information is passed to the UI, however only as static data. Meaning, if a user desires to manipulate these permissions in any way, they must do so via the helm only.
Fin
Measuring Success
By enacting RBAC via the UI, we were able to provide a more comprehensive tool with an emphasis on data security. We were able to listen to our users, hear their needs and surface a feature that was hidden in helm, in the UI. RBAC was well received and was the first step towards permission based features added to the Kubecost feature stack. This addition paved the way to land multiple partnerships including Apple and Nvidia, who were reliant on establishing a secure cost management solution that could span across the entire organization.
Thank You for Reading!
Thank you so much for taking the time to read this case study. As always, feedback is encouraged and welcomed with open arms! If you would like to read other case studies like this one, click here.