AuthZ and Workspace Management in OCM

Author: Anna | Last edit: October 16, 2024 | Design type: Lists, Modal, Wizard | Product area: Hybrid Cloud Console, OpenShift Cluster Manager, Managed Infrastructure

Overview

Value proposition

Why this matters

Customers have two requirements when doing business with Red Hat:

1. Allocate access to what they bought, to the people who are intended to derive value from it

2. Monitor the usage and cost of what they bought, against the value derived.

Currently, Red Hat makes it extremely challenging to accomplish this basic economy. _^[1]

The problem

“…by 2025, 80% of B2B sales interactions between suppliers and buyers will occur in digital channels.”

Problem 1: Subscribers receive monolithic entitlements (permissions) that prevent customers from governing access to metered services and support as they were marketed and sold.

Problem 2: We do not give customers the necessary authority or organizing structures to allocate and understand the access that is granted, its benefits, and its costs._^[1]

The data

Image of existing org model versus the org model by workspaces

Our customers are clear: our current model isn't working

86+ significant customers with access issues based on field surveys, tickets, cases, etc.
$1 billion average SYB across all customers known to be affected by access management challenges
50 million in deals at risk right now where customers are trying to negotiate centrally, then allocate to subsidiaries

_^[1][2][3]

Current model v. workspace management model

Current model:

Fixed, broad permissions
Limited and scattered RBAC implementations
No support for hierarchical structures
Poor visibility and reporting
Centralized, rigid access management

Workspace management model:

Flexible, dynamic permissions
Enhanced, customizable RBAC
Support for hierarchical structures
Enhanced monitoring and reporting
Decentralized, flexible workspace management

The problem as it relates to OCM: Inconsistent user experience for fine-grained access

Divided authorization experiences

There is an inconsistent user experience for administrators who wish to configure their user access within console.redhat.com for OCM Clusters.

Users and user groups are created and managed within console.redhat.com, while the role associations to those groups are managed within the OCM console.

Overprivileged org admins

The same issues related to the ‘flat org’ problem was solved in the MVP release for RHEL.

Clusters are impacted by overprivileged org admins who may inadvertently modify clusters they should not be able to see/edit.

How workspaces are intended to benefit OCM

Manage cluster access by workspace

Scope users and roles to clusters based on their workspace

Create sub-workspaces for granular access to clusters based on organizations' structure (projects, teams, and environments)

Consistent user experience between console and OCM

Consistent access management user experience between console.redhat.com and the OCM console

Image of a configuration organized by environments and workspaces

Sources:

_[1]_{Cloud services authorization ARB value proposition}_{| July 2023}

_[2]_{Customer & Partner Account and Access Management Survey}

_[3]_{Marketing Technology & Operations Data}

_[4]_{OCM RBAC}

OCM Goal

What are we trying to achieve?

To create an intuitive and efficient implementation of the new Kessel/AuthZ authorization model within OpenShift Cluster Manager (OCM) that aligns with the broader goals of the Hybrid Cloud Console (HCC) and Customer & Identity Management teams (CIAM). This model should ideally enable the next iteration of access control and support workspace hierarchy within the existing, unique Role-Based Access Control (RBAC) in OCM.

Resources

Valuable information that led us here

Design

2024 Enhanced Access Control (Workspace Management/AuthZ) for Console GPS (for new customers) / Deck

2024 Customer migration GPS (existing customers) / Deck

2024 Tenancy GPS / Deck

2024 Subscription management (WIP)

2024 OCM usage of AuthZ / Doc

Research

2023 CIAM outcome discovery report / Deck / Plan

2023 Cloud services authorization ARB / Deck

CIAM Program overview

Customer & partner access management survey

Marketing Technology & Operations data

Portfolio Life Cycle Management Data

Current model for access control in OCM (RBAC)

Design audit

Inspect OCM RBAC

Inspect how current role-based access control (RBAC) works in OCM

Image diagram illustrating how role-based access control works in OCM

Structure and management

Role assignments: Managed by organization administrators, scoped to individual clusters or all organization clusters.
Default Policies: Implicit policies allow members to view and provision clusters.

Limitations

Isolation: Independent operation from the rest of the HCC IAM service.
Permissions maintenance: Permissions associated with OCM roles are maintained exclusively within OCM and are not integrated into the HCC IAM service.

Permissions and roles

Cluster owner: User who provisions a cluster; full management rights.
Standard roles: Cluster Viewer, Provisioner, Editor; roles can be assigned to groups.
Group management: Admins create/manage groups, assign roles, control membership.

^[4]

Design exploration

How this impacts the experience in OCM

User flow exploration overview

Image of an overview of the day 0, day 1, and day 2+ experience

Day 0: Discover and learn (collaborative work with HCC / tbd)

OCM users will learn about the concept of workspaces externally and potentially in-product at various touch points

Day 1: Evaluate and adopt

OCM admins within their respective access in the workspace hierarchy in their organization will be able to create clusters within a global or specified workspace potentially in both the ROSA wizard/CLI

Day 2+: Expand: OCM admins within their respective access in workspace hierarchy will be able to change which workspace a cluster is in from the cluster list overview and potentially from the individual cluster details after the cluster has already been created

OCM design flow exploration

Day 1: Creating a cluster in a workspace

ROSA HCP wizard

[Figma mocks]

OCM admins will be able to create a cluster within either the default workspace in their organization or within another specified/active workspace during the ROSA HCP cluster creation process in the wizard.

OCM admins will be able to search directly for an existing workspace from the filter field within the dropdown, in the same convention as the other dropdown fields in the wizard.

Overall, it will mostly follow the PatternFly tree search behavior.

Additionally, if there is a single direct match, the dropdown ‘highlights’ the workspace.

This mechanism will be applied to all of the other OCM wizards: ROSA classic, OSD, and ARO with appropriate considerations applied for those use cases.

OCM admins will be able to confirm their workspace selection at the review step of the create cluster process in the ROSA HCP wizard within the Details section.

Command line interface

OCM admins will be able to create a cluster within either the global workspace in their organization or another specified workspace during the ROSA cluster creation process in the CLI

(Final design implementation tbd)

Day 2: Moving a cluster(s) to a different workspace

Cluster list

[Figma mocks]

After a cluster has been created, OCM admins will be able to change the workspace that a cluster is in directly from the Cluster List, given their respective level of access in the workspace hierarchy.

Individual cluster details

After a cluster has been created, OCM admins will be able to change the workspace that a cluster is in from drilling into the specific cluster's details from the Cluster List, given their respectiuve level of access in the workspace hierarchy.