Skip to end of metadata
Go to start of metadata

You are viewing an old version of this content. View the current version.

Compare with Current View Version History

« Previous Version 9 Next »

Opsera platform: Users, Groups, and RBAC Management

This Document contains specific user guides and instructions related to Role Based Access Controls for your Opsera platform, from a description of how to set site access to group management, item level access, and pipeline access.  This Guide will take you through each step in the Table of Contents with screenshots to keep you on the path. 


Role Based Access Rules: Site and Item Level Group Management

The Opsera platform supports both top level Site access as well as individual item level access rules. All Role Based Access (RBAC) is driven by group membership. In the Platform settings, the Group Management UI allows for creation of custom groups that can be leveraged for item level access rules as well as Site Level membership management. At this time Item Level RBAC applies to both Pipelines and Tool Registry items. Fundamentally if an item (pipeline or tool) does not have an access rule applied, then all users will see and be able to use it. Once any rule is applied, then those rules will apply for the item going forward and if a user does not have visibility for that item, it will not even show up in the UI for other users.

Please note that Site Level Access: Administrator or Power Users supersede any item level access rules.

Site Level Access Roles

Opsera supports 4 levels of standard role based access using a groups model. The four tiers are: Administrators, Power Users, Users and Read Only*. From a system perspective, users can be added to either Administrators, Power Users or Users groups. A user not in any of those are read only.

*Read only is the default, and implied if the user is not defined as one of the other three. This is a security precaution to ensure that someone must deliberately grant a user access at the most basic level before they can start using pipelines or tools. 

NOTE: At this time, Platforms (Toolchain Automation) has no limitations related to these roles. That area of the site will be updated in the future to support that ability.

Viewing My Access Role

The my profile page (available from the top right nav bar drop down) gives you a view of what access the user has at that given time. It’s a good tool for troubleshooting access and other settings. In this context, if a user looks at their Profile, there is a “Platform Access Role” field that will indicate what site level role they are a member of. Obviously if a user is in two roles (administrator AND Power User for example) the site will choose the higher of the two privileges. The Groups Membership is also helpful to see all the groups a user is currently a part of. 

If a user’s role is changed, that change may not take effect until the user logs out and back in, or waits 20 minutes.

Group Management

Group Management is controlled via the Settings panel under the Groups UI. This tool is ONLY visible to the Administrators and Power User Roles at this time.

Site Role Access is managed in a separate space from normal groups, even though they are all (technically) groups. As such, ONLY Opsera and Site Administrators can manage those. Power Users are limited to standard group management only. At this time, a user must be a Power User to perform group management. 

The Group Manager allows users to administer membership for existing groups AND create new “User” groups. Once created, these groups can be used in individual Access Rules for pipelines or tools. Group Manager access is limited to Site Administrators or Power Users only. In the UI, users can either click on a group to manage membership OR they can create a new group. Please note, the different group types have different functions in the system. From a user access perspective Role types are Opsera level groups which users can manage membership for, but cannot change or create the groups itself. Departments (dept) exist but are not fully implemented yet.

Groups

Manage membership for existing groups and create new groups. These are custom groups that users can create, manage and apply to individual items. Once a group has been created, you can navigate to pipelines, tools, tasks, parameters and scripts and assign RBAC Access Rules and identify if group has Administrator, Manager, User or Guest access to that particular item. Users can create the groups - however there is no UI impact at this release.

Site Access Roles

The following site level roles are available in the system today. The expectation is that a few account owners or top level administrators would be the ONLY people in the Administrator role. These users would be responsible for onboarding customers and granting them the proper access. This should not be used to grant/hide access to Pipelines or Tools. These roles should primarily be thought about in terms of interacting with the entire platform: changing settings, managing users, deleting tools, and eventually managing Billing info or other Opsera account related settings, etc.

Administrator Group: Full system access, allowing them to perform all actions on Toolchain, Pipelines, Tool Registry, and Analytics/Notifications. In Pipelines, an Administrator can perform all actions on any pipeline just as if they were an Owner. Administrators also see all pipelines and tools, no matter what role settings are in place. So it’s important to limit who is in here.

Power Users Group: Power Users are intended to have the ability to work with more of the advanced settings of the Opsera platform: Group Management, Tags Management, elevated pipeline settings (for the pipelines they have access to), but not have the FULL account access of a Site Administrator. As such, they would NOT see everyone’s pipelines or tools, and so they would need to be granted Pipeline or Tool level access to see or work with individual objects. These users also do NOT get access to the “Updates” feature and they don’t have the ability to create or edit other user’s settings (this is more for in the future when we let customers manage their own users). 

Note: Many roadmap features will probably be granted access to this Site Role, but it is important to distinguish those who are responsible for the entire stack/account, whereas Power Users are responsible for their part of the stack. Opera development expects that Power Users may be filtered by department or other concepts in the future. 

Users Group: Users should be the basic group membership that everyone is a part of if they are actively using our system. This is a base level group that basically would allow users to view logs/blueprints/dashboards, create their own pipelines or register new tools, but not see anyone else’s (unless granted that access directly).

Read Only Access: This role is not completely flushed out yet, but the idea is that if you are not an active “pipeline/tool registry” user, then this role may be useful for Analytics/Dashboards and just individuals who want to look around the system. Eventually I would see this as being the default group we assign to any new user (in an LDAP Org) and then IF the user is going to start using our tools, then they get moved up to the Users group. But again, this is more in theory right now and we will have to flush it out.

Item Level Access Rules

Item level access rules are designed to apply users or groups to given objects in the system: Pipelines or Tools at this time. These policies will apply to the given item and its actions. By default, Site Administrators AND individual item Owners will always have full access to a given item. 

The owner of the pipeline will always have full access and visibility to that item, no matter what the roles settings are in relation to that user. If the user does not desire this access, they need to use the Transfer Pipeline feature to transfer ownership to someone else. Item level access can be applied to custom user groups OR individual users.

Following other platform models, IF a user does not have the proper access to a Pipeline or Tool, then the site will completely hide it from them. It will be as if the item doesn’t exist to the user, so they will not see it in the All Pipelines or Tool Registry table AND in the Logs/Blueprints UI, the pipeline will not show up in the drop down.

Pipelines

This functionality operates the same way as Tool Registry. If NO rules are applied, all users have access to an item. If specific rules are set (either via a custom group or direct user) then that takes over.

Access Role Type

Access Policy

Description

Owner

Full Access


Administrator

Full Access


Manager

Site Level Power User

Power User Type Policy

Please note, this role is the same as a Site Level Power User.

·   View Step Configuration

·   Edit Step Details

·   Publish a pipeline to catalog

·   Duplicate a Pipeline

·   Stop, Start, Reset Pipeline

·   Approve Step when pipeline is waiting (this may not apply via Slack, so have to flush out the services end on this still.)

·   Edit Access Roles

·   Edit Step Notification Rules

User

End User Type Policy

This is the standard user policy so it’s designed to give users just enough access to run, stop, reset pipeline. That’s it. As such they will see all pipeline activity logs too.

Guest

Read Only Access

This is used to allow a user to see a pipeline in the UI. They would have only read access to it but as such can search logs, view activity. Without this access, the user would not even know the pipeline exists.

Ownership - Tool Registry

This functionality operates the same way as Pipelines. If NO rules are applied, all users have access to an item. If specific rules are set (either via a custom group or direct user) then that takes over.

Access Role Type

Access Policy

Description

Owner

Full Access


Administrator

Full Access


Manager

Site Level Power User

Power User Type Policy

Please note, this role is the same as a Site Level Power User.

·   edit tool settings

·   user tool in pipeline (not implemented yet)

·   edit tool connection tab

·   edit tool job/project/ account tabs

·   create a tool

User

End User Type Policy

When complete, this will be the standard user policy where users can select and use the tool. This user should be able to see the tool log output. NOT YET COMPLETE. 

Guest

Read Only Access

When complete, this would imply the user can see the tool in the list so that they can see who the owner is, other location data or any attributes stored on the tool, BUT they could not use it. NOT YET COMPLETE. 

  • No labels