Market Problem

This Section: High-Level description of the Market Problem ie: Executive Summary

• As a customer of OpenShift layered products, I need to be able to fluidly, reliably and consistently install and use OpenShift layered product Kubernetes Operators into my ROSA STS clusters, while keeping a STS workflow throughout.
•  
• As a customer of OpenShift on the big cloud providers, overall I expect OpenShift as a platform to function equally well with tokenized cloud auth as it does with "mint-mode" IAM credentials. I expect the same from the Kubernetes Operators under the Red Hat brand (that need to reach cloud APIs) in that tokenized workflows are equally integrated and workable as with "mint-mode" IAM credentials.
•  
• As the managed services, including Hypershift teams, offering a downstream opinionated, supported and managed lifecycle of OpenShift (in the forms of ROSA, ARO, OSD on GCP, Hypershift, etc), the OpenShift platform should have as close as possible, native integration with core platform operators when clusters use tokenized cloud auth, driving the use of layered products.
• .
• As the Hypershift team, where the only credential mode for clusters/customers is STS (on AWS) , the Red Hat branded Operators that must reach the AWS API, should be enabled to work with STS credentials in a consistent, and automated fashion that allows customer to use those operators as easily as possible, driving the use of layered products.

Why it Matters

• Adding consistent, automated layered product integrations to OpenShift would provide great added value to OpenShift as a platform, and its downstream offerings in Managed Cloud Services and related offerings.
• Enabling Kuberenetes Operators (at first, Red Hat ones) on OpenShift for the "big3" cloud providers is a key differentiation and security requirement that our customers have been and continue to demand.
• HyperShift is an STS-only architecture, which means that if our layered offerings via Operators cannot easily work with STS, then it would be blocking us from our broad product adoption goals.

Illustrative User Stories or Scenarios

1. Main success scenario - high-level user story
   1. customer creates a ROSA STS or Hypershift cluster (AWS)
   2. customer wants basic (table-stakes) features such as AWS EFS or RHODS or Logging
   3. customer sees necessary tasks for preparing for the operator in OperatorHub from their cluster
   4. customer prepares AWS IAM/STS roles/policies in anticipation of the Operator they want, using what they get from OperatorHub
   5. customer's provides a very minimal set of parameters (AWS ARN of role(s) with policy) to the Operator's OperatorHub page
   6. The cluster can automatically setup the Operator, using the provided tokenized credentials and the Operator functions as expected
   7. Cluster and Operator upgrades are taken into account and automated
   8. The above steps 1-7 should apply similarly for Google Cloud and Microsoft Azure Cloud, with their respective token-based workload identity systems.
2. Alternate flow/scenarios - high-level user stories
   1. The same as above, but the ROSA CLI would assist with AWS role/policy management
   2. The same as above, but the oc CLI would assist with cloud role/policy management (per respective cloud provider for the cluster)
3. ...

Expected Outcomes

This Section: Articulates and defines the value proposition from a users point of view

• See SDE-1868 as an example of what is needed, including design proposed, for current-day ROSA STS and by extension Hypershift.
• Further research is required to accomodate the AWS STS equivalent systems of GCP and Azure
• Order of priority at this time is
  • 1. AWS STS for ROSA and ROSA via HyperShift
  • 2. Microsoft Azure for ARO
  • 3. Google Cloud for OpenShift Dedicated on GCP

Effect

This Section: Effect is the expected outcome within the market. There are two dimensions of outcomes; growth or retention. This represents part of the “why” statement for a feature.

• Growth is the acquisition of net new usage of the platform. This can be new workloads not previously able to be supported, new markets not previously considered, or new end users not previously served.
• Retention is maintaining and expanding existing use of the platform. This can be more effective use of tools, competitive pressures, and ease of use improvements.
• Both of growth and retention are the effect of this effort.
  • Customers have strict requirements around using only token-based cloud credential systems for workloads in their cloud accounts, which include OpenShift clusters in all forms.
    • We gain new customers from both those that have waited for token-based auth/auth from OpenShift and from those that are new to OpenShift, with strict requirements around cloud account access
    • We retain customers that are going thru both cloud-native and hybrid-cloud journeys that all inevitably see security requirements driving them towards token-based auth/auth.
    •  

References

• DR-66: Guided operator installs
• Design Document: STS enablement for operators on Managed OpenShift