Role-based access control for Red Hat Hybrid Cloud Console

Red Hat Hybrid Cloud Console uses role-based access controls (RBAC) to restrict network access to services and resources based on user roles.

Role permissions are either assigned or inherited through a role hierarchy and can be as broad—or granular—as needed, based on your requirements.

**Definitions and hierarchy **

Before we delve further into RBAC, let’s go over some basic terms:

• An organization is an account-level entity

• A user is an authenticated user within the organization

• An organization administrator is a user with elevated permissions who can manage user access for the organization

• A group is a collection of roles and users

• A role is a set of permissions

• A permission is a discrete action that can be requested of a service

• Role binding grants the permissions defined in a role to the user(s) of the associated group

It may help to think of it this way:

• Users belong to groups

• Groups are granted roles

• Roles are granted permissions

• Permissions allow specific operations to an application or resource

Visualizing user and group associations

The following diagram shows the association of users within an organization to a single group, which is bound to the permissions of a resource:

RBAC administration

The management of RBAC resources for your organization can only be performed by an organizational administrator. An organization may have one or more organizational administrators. This is something each organization needs to define for itself based on size and structure.

Restrictions

Hybrid Cloud Console RBAC has some restrictions and constraints:

• It does not support directly assigned roles or permissions to individual users. Users must be added to groups to inherit roles and permissions.

• It does not manage Red Hat OpenShift Cluster Manager permissions. All users in the organization can view OpenShift Cluster Manager information, but only an organizational administrator and cluster owners can perform actions on clusters.

• Authentication into Hybrid Cloud Console is done through Red Hat’s single sign-on (SSO) service. Account creation and user federation is handled outside the console. Group federation is not currently supported, but there are plans to integrate in the future.

Default access groups

There are two default groups that are associated with every new account on console.redhat.com. The default administrator access group and the default access group.

**Default administrator access group **

The default administrator access group is limited to organizational administrators in your organization. You cannot change or modify the roles in the default administrator access group.

**Default access group **

The default access group contains all authenticated users in your organization. These users automatically inherit a selection of predefined roles which are in the default access group.

If an organizational administrator does not want roles to be automatically inherited by all users, they can remove some (or all) of the roles from the default access group and then manage access by creating their own groups and adding users/roles to those groups.

Modifying the default access group by creating the custom default access group

If the default access group is modified by your organizational administrator in any way, it becomes the custom default access group.

The custom default access group will no longer automatically update when new roles are added to console.redhat.com. However—if you wish to be notified when Red Hat makes changes to the Default access group to help you decide whether to make the same changes to your Custom default access group—you can opt-in to certain notifications for RBAC. You can access these on the console notifications page and read more about configuring notifications here.

Restoring the default access group

If an organizational administrator modifies the default access group (thereby creating a custom default access group), but later decides they want to revert back to the original Default access group, they can select “Restore to default.”

This restores the default access group and removes the custom default access group. These changes cannot be undone, so the system will prompt the organizational administrator prior to continuing.

Examples of group memberships within Hybrid Cloud Console RBAC

In this example, you can see the organizational administrator is associated with both the default administrator access group and the default access group. Non-organizational administrator users are only associated with the default access group. If the default access group is modified to a custom default access group, the current users inherit the new group’s permissions.

Managing your users through RBAC

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 of which the user is a member.

Organizational administrators can assign permissions by adding or removing roles and users to/from a new or existing group.

Here are a few things to note regarding the user access structure:

• A user can be a member of one or many groups.

• A role can be added to one or many groups.

• A role can have one or many associated permissions.

**User access APIs **

The same endpoints are available to use through Hybrid Cloud Console RBAC application programming interface (API). This gives organizational administrators the ability to create automated user access workflows if desired.

Managing your groups

Here we’ll look at how to create and modify a new group.

Creating a new group

If new groups are required to give more granular permissions for specific users, use the “Create group” function found at console.redhat.com/settings/rbac/groups.

In this scenario, we’re creating a group for the purpose of providing some of your organization’s administrators malware detection administrator permissions/access.

1. Add name and description

1. Add roles (previously created)

1. Add members

1. Review details and submit

Now the users who were added to this group can perform any of the malware detection administrator functions, while users outside of this group will have no access to that sensitive information.

This type of modification can be done to accommodate your organization’s unique structure. Just remember: if the role exists as part of the default access group, all authenticated users will still have the associated permissions.

If you need to adjust the default access group, follow the steps below.

Modify an existing group

In this example, we will modify the default access group to remove the vulnerability administrator role. This allows the organizational administrator to create a separate vulnerabilities group that only includes the specific users that need access.

1. On the groups page, select the default access group.

2. There are two tabs—roles and members—select roles for this example.

3. Find the vulnerability administrator role and click the three dots to the right of the role. Then select remove.

1. You will be prompted to confirm the removal.

1. Click “Remove role” to confirm. The vulnerability administrator role is no longer associated with the default administrator group

Next steps

Refer to our user access and configuration guide on the Red Hat Customer Portal to learn more about user access, or log in to console.redhat.com to take a tour of this feature.