Uploaded image for project: 'OpenShift Container Platform (OCP) Strategy'
  1. OpenShift Container Platform (OCP) Strategy
  2. OCPSTRAT-2260

Support for managed identity in Azure to fetch protected assets from Azure Storage

XMLWordPrintable

    • Product / Portfolio Work
    • None
    • 100% To Do, 0% In Progress, 0% Done
    • False
    • Hide

      None

      Show
      None
    • False
    • None
    • None
    • None
    • None
    • None
    • None
    • None

      Feature Overview (aka. Goal Summary)

      An elevator pitch (value statement) that describes the Feature in a clear, concise way. Complete during New status.

      • Enable OpenShift clusters on Azure to securely fetch protected assets from Azure Storage using Azure Managed Identities, mirroring AWS IAM role capabilities for Ignition.

      Goals (aka. expected user outcomes)

      The observable functionality that the user now has as a result of receiving this feature. Include the anticipated primary user type/persona and which existing features, if any, will be expanded. Complete during New status.

      • As an OpenShift user on Azure, I can use Azure Managed Identities for secure authentication to Azure Storage for both infrastructure components (e.g., internal image registry, Loki storage backend, node VHDs) and applications utilizing Azure file shares (via azure-file and azurefile-csi storage classes).
      • I can fetch protected Ignition files via Azure Managed Identity, reducing reliance on IP access control for critical cluster information.
      • I can simplify credential management by eliminating the use of Storage Account keys, enabling the disabling of "Allow storage account key access" for compliance.
      • I can align OpenShift's Azure Storage authentication with security policies requiring Entra ID (Managed Identity) based authentication.

      Requirements (aka. Acceptance Criteria):

      A list of specific needs or objectives that a feature must deliver in order to be considered complete. Be sure to include nonfunctional requirements such as security, reliability, performance, maintainability, scalability, usability, etc. Initial completion during Refinement status.

      • Ignition Integration: Ignition must fetch assets from Azure Storage using an Azure User-Assigned Managed Identity.
      • Azure Identity Utilization: RHEL CoreOS must utilize Azure User-Assigned Managed Identities for authentication to Azure Storage.
      • Installer Support: The OpenShift Installer must facilitate the assignment of Azure User-Assigned Managed Identities <to cluster VM Scale Sets>.
      • Security: Ignition files containing private/critical cluster information must be protected via Azure Managed Identity capabilities, allowing access only for authorized resources.
      • Infrastructure Component Access: OpenShift infrastructure components (e.g., internal image registry, Loki storage backend, node VHD) must be able to authenticate and access Azure Storage blob containers using Azure Managed Identity.
      • Application Storage Access: Applications using azure-file and azurefile-csi storage classes must be able to access file shares in Azure Storage Accounts over CIFS using Azure Managed Identity, supporting both dynamically and statically provisioned PVs.
      • Compliance Enablement: The solution must allow customers to disable "Allow storage account key access" in their Azure Storage accounts without breaking OpenShift functionality.

      Anyone reviewing this Feature needs to know which deployment configurations that the Feature will apply to (or not) once it's been completed. Describe specific needs (or indicate N/A) for each of the following deployment scenarios. For specific configurations that are out-of-scope for a given release, ensure you provide the OCPSTRAT (for the future to be supported configuration) as well.

      Deployment considerations List applicable specific needs (N/A = not applicable)
      :--- :---
      Self-managed, managed, or both both
      Classic (standalone cluster)  
      Hosted control planes  
      Multi node, Compact (three node), or Single node (SNO), or all  
      Connected / Restricted Network Connected
      Architectures, e.g. x86_x64, ARM (aarch64), IBM Power (ppc64le), and IBM Z (s390x) N/A
      Operator compatibility N/A
      Backport needed (list applicable versions)
      UI need (e.g. OpenShift Console, dynamic plugin, OCM) N/A
      Other (please specify) Requires appropriate Azure RBAC on Storage account and permissions for Managed Identity assignment.

      Use Cases (Optional):

      • Secure Infrastructure Component Data: OpenShift internal image registry, Loki storage backend, and node VHDs leverage Managed Identity for secure access to Azure Storage blob containers, replacing insecure Storage Account keys.
      • Compliant Application Storage: Applications requiring persistent storage via azure-file and azurefile-csi storage classes (dynamic/static PVs) can access Azure file shares over CIFS using Managed Identity, satisfying security policies.

      Background

      Provide any additional context is needed to frame the feature. Initial completion during Refinement status.

      • Ignition currently supports AWS IAM roles for fetching protected assets from S3. Similar capabilities are requested for Azure Storage using User-Assigned Managed Identities. This is crucial for protecting private/critical Ignition files that contain OpenShift 4 cluster information.

      Customer Considerations

      Provide any additional customer-specific considerations that must be made when designing and delivering the Feature. Initial completion during Refinement status.

      • Customers require enhanced protection for sensitive Ignition files beyond IP access control, leveraging Azure Managed Identity for authorization.
      • This directly impacts their ability to meet organizational compliance requirements and enable a hardened security posture by disabling insecure authentication methods.

      Interoperability Considerations

      Which other projects, including ROSA/OSD/ARO, and versions in our portfolio does this feature impact? What interoperability test scenarios should be factored by the layered products? Initial completion during Refinement status.

      Affected Components:

      • RHEL CoreOS
      • Ignition
      • Installer
      • Internal Registry
      • Storage

              linnguye.openshift Linh Nguyen
              linnguye.openshift Linh Nguyen
              None
              None
              None
              None
              None
              None
              Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

                Created:
                Updated: