Goals

Establish a common and simplified configuration experience for Red Hat Quay on Azure Identity-enabled OpenShift clusters using the new, standardized configuration flow described in OCPSTRAT-517. Users have a repeatable process to configure the Quay operator for Azure Identity with well-known inputs and behavior and can reuse the knowledge about that process with other operators.

Non-Goals

Support for any older version of OCP than 4.15.

Motivation

With OCPSTRAT-517, the support for Azure Identity authentication will well established in our core platform but we need to avoid creating fragmented UX among our layered products and OLM-managed operators. The configuration experience should be the same across individual OLM-managed operators that support Azure Identity. OCPSTRAT-6 aims to solve this for all cloud providers using the CloudCredentialOperator (CCO) and its CredentialRequest API.

Based on this, customers get a repeatable and simple experience of installing and configuring the Quay operator, or any OLM-managed operator that supports it, for tokenized authentication with their cloud provider.

The Quay operator has been identified as an operators capable of integrating with Azure APIs and therefore should support that new flow to act on customer feedback from customers of ARO or self-managed OCP on Azure.

Azure Identity-enabled API communication is considered a security-relevant issue for a majority of the customers and increasingly becomes a hard requirement.

Pre-work:

Feasibility study: https://docs.google.com/document/d/1b53-JaycqgRUkUwVXKXqSpzQnJWZj2cdXHgv-ErmcSs/edit

Acceptance Criteria

• the Quay operator implements the standardized configuration flow for Azure Identity-enabled clusters using CCO and CredentialRequests described here: https://docs.google.com/document/d/1iFNpyycby_rOY1wUew-yl3uPWlE00krTgr9XHDZOTNo/edit#
• the Quay operator gracefully falls back to regular operations when no service principal information is provided
• the Quay operator degrades when the service principal is provided but CCO does not reconcile the CredentialRequest (either due to a bug or due to running on an older than OCP 4.14 release)
• the Quay operator documents what specific permissions are needed when integrating with Azure using Azure Identity and provides easy to consume instructions to create those
• the Quay operator supports this workflow and provides the documentation from the appropriate release onwards

Risk and Assumptions

• Assumption: you don't currently have an existing way to integrate with Azure Identity
• Risk: if the above assumption is wrong, you need to deprecate this configuration flow in favor of the flow defined in OCPSTRAT-517

Documentation Considerations

• the Quay operator should rely on documentation the OLM portion of the OCP docs on how to carry out the configuration flow using either the OCP console or the CLI
• the Quay operator in its own documentation section shall supply the required IAM credential instructions