Feature Overview

Users of the OpenShift Console leverage a streamlined, visual experience when discovering and installing OLM-managed operators in clusters that run on cloud providers with support for short-lived token authentication enabled. Users are intuitively becoming aware when this is the case and are put on the happy path to configure OLM-managed operators with the necessary information to support AWS STS.

Goals:

Customers do not need to re-learn how to enable AWS STS authentication support for each and every OLM-managed operator that supports it. The experience is standardized and repeatable so customers spend less time with initial configuration and more team implementing business value. The process is so easy that OpenShift is perceived as enabler for an increased security posture.

Requirements:

• based on OCPBU-559 and OCPBU-560, the installation and configuration experience for any OLM-managed operator using short-lived token authentication is streamlined using the OCP console in the form of a guided process that avoids misconfiguration or unexpected behavior of the operators in question
• the OCP Console helps in detecting when the cluster itself is already using AWS STS for core functionality
• the OCP Console helps discover operators capable of AWS STS authentication and their IAM permission requirements
• the OCP Console drives the collection of the required information for AWS STS authentication at the right stages of the installation process and stops the process when the information is not provided
• the OCP Console implements this process with minimal differences across different cloud providers and is capable of adjusting the terminology depending on the cloud provider that the cluster is running on

Use Cases:

• High-level mockups found here: Operators & STS
• A cluster admin browses the OperatorHub catalog and looks at the details view of a particular operator, there they discover that the cluster is configured for AWS STS
• A cluster admin browsing the OperatorHub catalog content can filter for operators that support the AWS STS flow described in OCPSTRAT-171
• A cluster admin reviewing the details of a particular operator in the OperatorHub view can discover that this operator supports AWS STS authentication
• A cluster admin installing a particular operator can get information about the AWS IAM permission requirements the operator has
• A cluster admin installing a particular operator is asked to provide AWS ARN that is required for AWS STS prior to the actual installation step and is prevented from continuing without this information
• A cluster admin reviewing an installed operators with support forAWS STS can discover the related CredentialRequest object that the operator created in an intuitive way (not generically via related objects that have an ownership reference or as part of the InstallPlan)

Out of Scope

• update handling and blocking in case of increased permission requirements in the next / new version of the operator
• more complex scenarios with multiple IAM roles/service principals resulting in multiple CredentialRequest objects used by a single operator

Background

The OpenShift Console today provides little to no support for configuring OLM-managed operators for short-lived token authentication. Users are generally unaware if their cluster runs on a cloud provider and is set up to use short-lived tokens for its core functionality and users are not aware which operators have support for that by implementing the respective flows defined in OCPBU-559 and OCPBU-560.

Customer Considerations

Customers may or may not be aware about short-lived token authentication support. They need to proper context and pointers to follow-up documentation to explain the general concept and the specific configuration flow the Console supports. It needs to become clear that the Console cannot 100% automate the overall process and some steps need to be run outside of the cluster/Console using Cloud-provider specific tooling.