Feature Overview (aka. Goal Summary)

Support ARO and customers aspiring to follow Microsoft Azure security recommendations by allowing the Azure storage account hosting the object storage bucket for the integrated registry to be configured as "private" vs. the default public.

Goals (aka. expected user outcomes)

OpenShift installations on Azure can be configured so that they don't trigger the Azure's Security Advisor anymore with regard to the use of a public endpoint for the Azure storage account created by the integrated registry operator.

Requirements (aka. Acceptance Criteria):

• Manual private storage account configuration via the Integrated Registry operator's CR
• Automatic discovery of vnet and subnet resources requiring the end user to only set a single flag of the Integrated Registry operator CR to "internal"

Background

Several users noticed warnings in Azure Security advisor reporting the potentially dangerous exposure of the storage endpoint used by the integrated registry configured by its operator. There is no real security threat here because despite the endpoint being public, access to it is strictly locked down to a single set of credentials used by the internal registry only.

Still customers need to be able to deploy cluster that out of the box do not violate Microsoft security recommendations.

This feature sets the foundation for OCPSTRAT-997 to be delivered.

Customer Considerations

Customers updating to the version of OpenShift that delivers this feature shall not have their integrated registry configuration updated automatically.

Documentation Considerations

We require documentation in the section for the integrated registry operator that describes how to manually configure the vnet and subnet that shall be used for the private storage endpoint in case the customer wants to leverage an network resource group account different from the cluster.

We also require documentation that describes the single tunable for the integrated registry operator that is required to be set to "internal" to automate the detection of existing vnet and subnets in the network resource group of the cluster as opposed to manual specification of a user-defined vnet/subnet pair.