Uploaded image for project: 'OpenShift Request For Enhancement'
  1. OpenShift Request For Enhancement
  2. RFE-7704

Improve Entra ID Authentication for ARO with Conditional Access

XMLWordPrintable

    • Icon: Feature Request Feature Request
    • Resolution: Unresolved
    • Icon: Major Major
    • None
    • None
    • ARO
    • None
    • Product / Portfolio Work
    • None
    • False
    • Hide

      None

      Show
      None
    • None
    • None
    • None
    • None
    • None
    • None
    • None
    • None

      This RFE addresss a design issue in Azure Red Hat OpenShift (ARO) that impacts customers utilizing Microsoft Entra ID for in-cluster authentication with Conditional Access policies.

      1. The Challenge: Unpredictable Egress IPs and Conditional Access

      Currently, when an ARO cluster is configured with egress lockdown, traffic destined for the public Microsoft Entra ID endpoint is routed through the ARO management infrastructure via a private link. This traffic then egresses to the internet from a pool of IP addresses managed by the ARO service. These egress IPs are not static; they change frequently, particularly with new ARO releases.

      This poses a significant challenge for customers who leverage Entra ID Conditional Access policies to secure their clusters. A common security posture is to restrict access to Entra ID applications from known and trusted IP addresses. Due to the dynamic and unpublished nature of the ARO egress IPs, it is impossible to create a reliable and future-proof Conditional Access policy. This forces customers to choose between two undesirable options:

      • Disabling IP-based Conditional Access: This significantly weakens the security posture of the Entra ID integration.
      • Attempting to manually track and update IPs: This is a reactive and labor-intensive process, prone to errors and leading to unexpected outages when the IPs change without notice.

      The current situation creates a frustrating and insecure experience for security-conscious ARO customers.

      2. Proposed Solutions

      We propose four potential solutions to address this issue, listed in descending order of preference based on their anticipated effectiveness and elegance.

      2.1. Enable a Private Endpoint for Microsoft Entra ID

      The most robust and secure solution would be for Microsoft Entra ID to offer a private endpoint. This would allow ARO clusters to connect to the authentication service over a private, secure connection within the Azure network, completely obviating the need for public egress and the associated IP address challenges. This aligns with modern cloud security best practices and the capabilities of other Azure services.

      Benefits:

      • Eliminates the need for public IP whitelisting.
      • Enhances security by keeping authentication traffic off the public internet.
      • Provides a long-term, scalable, and architecturally sound solution.

      2.2. Create a Service Tag for ARO and Add Service Tag Support to Conditional Access

      A viable alternative would be the creation of an official Azure service tag for ARO egress traffic. Service tags simplify network security rules by representing a group of IP address prefixes for a given Azure service. While Conditional Access does not currently support service tags for defining network locations, this RFE would also serve as a request to add this capability to Microsoft Entra ID.

      Benefits:

      • Simplifies Conditional Access policy management by removing the need to manage individual IP addresses.
      • Provides a dynamic and automatically updated list of ARO egress IPs.

      Dependencies:

      • Creation of a dedicated service tag for ARO egress IPs by the Azure networking team.
      • An update to Microsoft Entra Conditional Access to allow the use of service tags in location policies.

      2.3. Selectively Bypass Egress Lockdown for Entra ID Traffic

      A third option would be to modify the ARO egress lockdown feature to allow specific, well-known endpoints like those for Entra ID to bypass the private link proxy and egress directly from the customer's virtual network. This would give customers direct control over the source IP address used for authentication traffic.

      Benefits:

      • Provides customers with direct control over the egress IP for Entra ID authentication.
      • Could potentially be implemented more quickly than the preceding options.

      Considerations:

      • This approach might be seen as counter to the all-encompassing nature of the egress lockdown feature.
      • It would require careful implementation to ensure only the intended traffic is bypassed.

      2.4. Publish and Maintain a List of ARO Egress IPs

      The least desirable, yet still an improvement over the current situation, would be for Microsoft to publish and proactively maintain a list of all possible ARO egress IP addresses for each region.

      Benefits:

      • Provides customers with the information needed to configure Conditional Access policies.

      Drawbacks:

      • This is a reactive and cumbersome solution for customers, requiring constant monitoring of the published list and manual updates to their security policies.
      • It is prone to human error and can still lead to outages if the list is not updated in a timely manner.

      3. Conclusion

      The current interaction between ARO egress lockdown and Entra ID Conditional Access presents a significant security and operational challenge for customers. We strongly advocate for a permanent and robust solution, with a private endpoint for Entra ID being the ideal architectural resolution. We are eager to collaborate with the Azure Red Hat OpenShift and Microsoft Entra product teams to find a viable path forward that enhances the security and usability of the ARO platform.

              Unassigned Unassigned
              rh-ee-dcoronel David Coronel
              None
              Votes:
              3 Vote for this issue
              Watchers:
              3 Start watching this issue

                Created:
                Updated:
                None
                None