Uploaded image for project: 'OpenShift API for Data Protection'
  1. OpenShift API for Data Protection
  2. OADP-5221

[Documentation for] Support the standardized Azure Identity configuration flow via OLM and CCO for OADP in OCP 4.15

XMLWordPrintable

    • Icon: Task Task
    • Resolution: Unresolved
    • Icon: Major Major
    • OADP 1.3.5, OADP 1.5.0
    • OADP 1.3.5, OADP 1.4.2
    • Documentation
    • None
    • 3
    • False
    • Hide

      None

      Show
      None
    • False
    • ToDo
    • 0
    • 0.000
    • Very Likely
    • 0
    • None
    • Unset
    • Unknown
    • None

      Goals

      Establish a common and simplified configuration experience for OADP on Azure Identity-enabled OpenShift clusters using the new, standardized configuration flow described in OCPSTRAT-517. Users have a repeatable process to configure the OADP operator for Azure Identity with well-known inputs and behavior and can reuse the knowledge about that process with other operators. The support should be introduced in a release of the OADP operator with OpenShift 4.15.

      Motivation

      Today, the support for Azure Identity authentication is well established in our core platform but fragmented at best among our layered products and OLM-managed operators. The configuration experience is also different between 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 OADP operator, or any OLM-managed operator that supports it, for tokenized authentication with their cloud provider.

      The OADP operator has been identified as an operators capable of integrating with Azure APIs and therefor should support that flow to act on customer feedback from ARO customers.

      Short-lived token-enabled API communication via mechanisms like Azure Identity is considered a security-relevant issue for a majority of the customers and increasingly becomes a hard requirement.

      Alternatives

      None.

      Acceptance Criteria

      • the OADP operator implements the standardized configuration flow for Azure Identity-enabled clusters using CCO and CredentialRequest, the exact flow is not ready but will be provided once OCPSTRAT-517 progress (but you can expect it to be almost identity to the AWS STS flow described (here)https://docs.google.com/document/d/1iFNpyycby_rOY1wUew-yl3uPWlE00krTgr9XHDZOTNo/edit#)
      • the OADP operator gracefully falls back to regular operations when no role ARN is provided
      • the OADP operator degrades when the role ARN 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 OADP operator documents what specific IAM permissions are needed when integrating with Azure using Azure Identity and provides easy to consume instructions to create those
      • the OADP 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 OADP 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 OADP operator in its own documentation section shall supply the required IAM credential instructions

              rhn-support-shdeshpa Shruti Deshpande
              talayan@redhat.com Tareq Alayan
              Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

                Created:
                Updated: