...

...

Role Based Access

...

:

...

Platform Role and Item Level Based Group Management

The Opsera platform supports both top platform level Site access roles as well as individual item level access rules. All Role Based Access (RBAC) Users are assigned one of 3 Platform Roles, but item level access 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 Group membership can be managed by Site Admins and Power Users via the Settings area in the portal.

Individual users and groups are then assigned to Pipelines, Tasks, Tools in Registry as well as other core features of the product. The owner or delegated users can then manage this access at the item level.

Individual Access Rules can be applied to Pipelines, Tasks, KPI Dashboards, Scripts and Custom Parameters. By default, however if an item (pipeline or , tool, etc) does not have an access rule applied, then all users will see and be able to use it. Once any Only after a 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 userswith RBAC controls apply to that time.

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

...

Platform Roles

Opsera supports 4 3 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.

...

Platform Roles: Administrator, Power User and User. Any user who is not one of those three is considered a Guest and defaults to “read-only” access.

Administrators can manage Role Levels in the Settings → Site Roles screens.

If a user is not assigned any role, then they are considered a Guest with standard read only access: they see whatever items have NO RBAC Access Rules applied and can create their own pipelines, tools, etc but cannot interact with any pipelines, tasks or tools that they are not explicitly granted access to via RBAC Access Rules.

Viewing My Platform 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.

...

Image Removed

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 In here Admins and Power Users can create any group model that fits for the organization or team structure. Then users can be added accordingly. These groups are then available for assignment in the Access Rules for pipelines, tasks, etc.

...

Administrators and Power Users can add and remove gropu access*.

...

_{*Please note, changes to group membership can take up to 20min to take effect depending on caching timeouts.}

...

Platform Role Definitions

Administrator: Full system access, allowing user to perform all actions on Toolchain, Pipelines, Tool Registry, Tasks, Tag and Analytics/NotificationsData Mapping Management, Analytics, etc. In Pipelines and Tasks, 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 an Administrator. As such, they would NOT see everyone’s pipelines or tools, and so they would need to still 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 systemmost common role in use. 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.

...

for using all of the features of Opsera in accordance with the Access Rules for individual items.

Guest / Read-Only: This is not explicitly a role, rather it is the lack of role. Any user with no role assigned is treated as a guest with no ability to see anything that already has RBAC rules assigned (please note if tools, pipelines, tasks are wide open and do not have Access Rules defined even Guests would be able to see them). The intention with this classification is primarily to allow any user to log into Opsera and view Insights or Analytics but not to use the Orchestration and Tool Chain capabilities.

_{*An Owner of a pipeline, task, tool, ect is always going to have full access to that item. This is why Opsera offers a way to transfer ownership to another user. Owner of a pipeline or task shoudl be considered an “Administrator” of that item.}

...

Access Rules: Pipelines, Tasks, Tools, etc

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. 

...