Red Hat is pleased to introduce user access, a Role Based Access Control (RBAC) capability that can be used to control user access to Red Hat Insights and cloud management services for Red Hat Enterprise Linux (RHEL), on cloud.redhat.com. In this post we'll look at how RBAC applies to our services, what it can do for your organization, and what you need to know to make use of user access.
As you may already know, RBAC is a method for restricting account users access only to the services and information they need.
Who can access this feature?
The ability to view and manage user access on cloud.redhat.com is available only to Organization Administrators on entitled accounts.
This is because user access requires user management capabilities that are defined on access.redhat.com, which is currently only designated to org admins.
How does user access work?
Red Hat customer accounts can have hundreds of associated users, and not all of those users need the same level of access to the various services that are available on cloud.redhat.com. This enables Organization Administrators to start managing user access to Insights and Cloud Management Services; additional roles and capabilities will be introduced in upcoming releases.
User access: An Additive Model
User access is additive, meaning there are no ‘deny’ permissions. An individual user’s permitted access is determined by all roles that are assigned across all groups that a user is a member of.
Org admins can assign permissions by adding or removing roles and users to/from a new or existing group that has been created by an org admin on the account. We have an example coming up.
Group: A collection of users belonging to an account and provide the mapping of roles to users. Org admins can use groups to assign one or more roles to one or more users.
Roles: A set of permissions that guard access to a given service (e.g. Compliance).
Permissions: A discrete action that can be requested of a service.
User access structure:
A given user can be a member of one or many groups.
A given role can be added to one or many groups.
A given role can have one or many associated permissions.
By default, all account users will inherit the roles listed in the "Default user access" group or (if it has been modified) the "Custom default user access" group.
Managing Default user access
For this initial release, each service has adopted a model in which any authenticated account user will inherit access roles by default via the Default user access group. This is in support of a more streamlined introduction of RBAC to the cloud.redhat.com user base. This means that any services which users could access prior to the introduction of RBAC will continue to be accessible until/unless an account organization (org) admin uses the new user access feature to change access rights.
The access roles that apply to any new services that are introduced on cloud.redhat.com may automatically be added to the Default user access group.
The Default user access group cannot be deleted, but it can be customized by Org admins who wish to change what roles, if any, are included. When customization is initiated (by adding and/or removing roles), the name of the Default user access group will automatically change to "Custom default user access" if any roles are added and/or removed.
Additionally, cloud.redhat.com will no longer automatically update the roles within a Custom default user access group. For example, a role for a brand new service on cloud.redhat.com will not automatically be added to a "Custom default user access" group, but it will automatically be added if it is a "Default user access" group.
If an org admin does not want any roles to be automatically inherited by all users, he or she can remove all of the roles from the Default user access group and manage access only by adding users/roles to groups that they create.
Example Use Case with user access
Security user ‘Sam’ should only be able to access the Vulnerability service. The Default user access group has roles that allow access to Vulnerability as well as additional services, and Sam will inherit all of these roles from the Default user access group.
‘Pat’ is an org admin and is going to use user access to make sure that Sam has only the access he needs.
Pat will start by removing all roles from the Default user access group because the default behavior for that group is to give access to all users to all services. If Pat does not make this change, Sam will inherit roles that allow for additional access to services beyond Vulnerability.
Note: Adding or removing any or all roles from the Default User Access group adds or removes those roles for all users. Users will retain permissions from other groups they belong to, of course.
Pat will then create a group called ‘Security Admin’, and add a role that grants full access to the Vulnerability service. Sam will be added as a member of this Security Admin group.
Now, Sam has full access to only the Vulnerability service and is not inheriting any additional access from the Default User Access group.
User access APIs
The same endpoints are available to use via API for any account so that an org admin can build an automated user access workflow, if they choose to do so.
To get started, refer to the user access configuration guide to learn more about User Access or log in to cloud.redhat.com to take a tour of this new feature.
Additionally, Red Hat Insights is included at no additional charge in your Red Hat Enterprise Linux subscription. If you have not already enabled Red Hat Insights, review the Getting Started page. If you have questions or comments email email@example.com.