Transitioning Red Hat Subscription Management to the Hybrid Cloud Console
Transitioning Red Hat Subscription Management to the Hybrid Cloud Console
Prerequisites: Enable simple content access and subscription reporting
Before beginning your transition you will need to make sure that simple content access (SCA) and subscription reporting are enabled.
Click the links below to learn more.
Step 1: Explore the new subscription and system management experience
The most important thing for you to know is that no action is required by you, other than updating your bookmarks for the subscription and system management tasks you frequently complete. Systems registered to Red Hat Subscription Management are already waiting for you on the Hybrid Cloud Console. However, there are small changes to some of your most commonly-used workflows.
Purchased subscriptions and usage
With simple content access, subscriptions are no longer attached to hosts or activation keys, and the subscription experiences at the Hybrid Cloud Console do not support those workflows. View your product usage via the subscriptions service and view your purchased subscriptions via the subscription inventory.
Managing Satellite manifests
If you have a connected Satellite environment, you can manage the subscriptions on your manifest from within the Satellite interface. All you need to do on the Hybrid Cloud Console is create and export a new manifest, when needed. You can also see the current list of subscriptions for each manifest in your organization.
Registering systems with activation keys
Functions supporting system entitlement workflows are removed from activation keys on the Hybrid Cloud Console. Instead, activation keys can set system purpose, which is helpful for more accurate subscription usage reporting, and enable additional repositories during system registration to better support extended support and common workloads. You should remove entitlements from any activation keys you plan to continue using.
System inventory
The host inventory on the Hybrid Cloud Console includes all RHEL systems connected to Red Hat, which could include Red Hat Subscription Management, Red Hat Insights, and systems reported by Red Hat Satellite and Discovery. You can filter the inventory by each source, if you are uncertain about how each system is connected.
System updates and security
In addition to the errata, or advisory, reporting that you are familiar with from the Customer Portal, the Hybrid Cloud Console platform provides analysis related to the security and deployment of software installed in your environment. Vulnerability analysis is provided to show you which CVEs are affecting your systems to help keep your environment secure. A package analysis shows you all of the packages installed across your environment and which version of that package is installed on each system.
Next steps
Over time, additional tasks and workflows will move from the Customer Portal to the Hybrid Cloud Console, but for now, the Customer Portal is still your home for:
- Creating and managing manifests for disconnected Satellites
- Cloud Access workflows to gain access to Red Hat gold images
- Digital renewals
Ready for more? Please continue reading for additional setup related to permissions and notifications.
Step 2: Set up user groups and permissions
Permissions on the Hybrid Cloud Console work a little differently than the Customer Portal and are based on a role-based access control (RBAC) model.
Users are added to user groups, permissions are added to role definitions, and those role definitions are applied to the user groups.
This RBAC model gives you more control over which users are able to access and manage various subscription management workflows in your organization.
The most important impact of this new model is that you can better manage which of your users can see certain sets of systems that are registered to your organization.
All Org Admins are included in the “Default Admin Access” user group, which includes all of the roles you need to access and manage your subscription management experience. Similarly, all other users are included in the “Default Access” user group, which includes all of the roles required to access your subscription management experience.
By default, all users have access to items they might not have been able to access on the Customer Portal, including all registered systems and all activation keys.
To change this default behavior, roles must be removed from the Default Access group and added to new custom user groups, as needed.
For example, if only some of your users should be allowed to see which Red Hat product advisories are impacting your environment, you would:
Create a new user group containing the users who *should* be able to see the advisories. For example: “My Patch Viewers”
Add the “Patch viewer” role to the new group you created.
Remove the “Patch viewer” role from the Default Access user group, which is automatically renamed to “Custom Default Access”
From this point forward, only users who you explicitly add to the “My Patch Viewers” user group will be able to see information about which product advisories are applicable to your environment.
Step 3: Create system groups and assign access to your user groups
On the Customer Portal, there are three permissions that control access to systems: View/Edit All, View All, and View/Edit User’s Only.
This is an effective access model for some organizations, but has limitations, particularly for organizations that use activation keys to register systems.
On the Hybrid Cloud Console, the default state is that all users have the Inventory Hosts Administrator role.
It is important to understand that there are very limited administration features in the Hybrid Cloud Console Inventory.
An Inventory Host Administrator can see the system profiles, edit the display name of the system profile, and delete the system profile.
None of these administration activities changes anything on the system itself.
This is different from the Customer Portal, where a user can edit values, such as system purpose or assigned entitlements, which impact the system itself.
To change this default access, you can make use of Inventory Groups.
Inventory Groups provide you with a way to organize your registered systems in a way that reflects your environment and can be used to filter views of your Inventory.
For example, if different members of your team support RHEL systems in North America and Europe, you could group those two sets of systems so that the team member who only supports the systems deployed in North America can filter their views to only those systems.
Let’s take that example a step farther and say that your North American team member should not be able to see the systems assigned to your European inventory group. To accomplish this:
Create a new role called, for example, “North America Inventory Administrator”
During the creation of this role, select the inventory:hosts:read and inventory:hosts:write permissions
Select the North America inventory group to assign each of those permissions
Save the new role and repeat to create a “Europe Inventory Administrator” role.
Create two new user groups called, for example, “North American Admins” and “European Admins”, and add the appropriate user(s) to each user group.
Add the “North America Inventory Administrator” role to the “North American Admins” user group and the “Europe Inventory Administrator” role to the “European Inventory Admins” user group.
Finally, remove the “Inventory Host Administrator” role from the Default Access user group.
Inventory Groups
Step 4: Set up Notifications and Events
The Hybrid Cloud Console experience provides many new ways to get alerted to changes in your environment, including email notifications, integrations with tools like Splunk, ServiceNow, Event-Driven Ansible, Microsoft Teams, Slack, or Google Chat, and webhooks to create alerts in other third-party productivity tools.
For now, let’s focus on email notifications, as that is the most similar to the Customer Portal experience.
On the Hybrid Cloud Console, email notifications are a two step process:
An Org Admin selects which notifications are available to which groups of users and then individual users within those groups choose how they want to receive those notifications.
To enable email notifications for your organization, you will first need to create a behavior group.
A behavior group maps a group of users to a set of events they can be notified about and how they can be notified.
As a simple example, if you wanted everyone in your organization to be able to receive email notifications when a new product advisory, or erratum, affects your RHEL environment, you would:
Create a new behavior group
Select an action of “Send an email” and a Recipient of “All”
Select the “New advisory” event type
Confirm the new behavior group
