Bug 1943175 - unable to install IPI PRIVATE OpenShift cluster in Azure due to organization policies (set azure storage account TLS version default to 1.2)
Summary: unable to install IPI PRIVATE OpenShift cluster in Azure due to organization ...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: Installer
Version: 4.7
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: ---
: 4.8.0
Assignee: Etienne Simard
QA Contact: To Hung Sze
URL:
Whiteboard:
Depends On:
Blocks: 1958376
TreeView+ depends on / blocked
 
Reported: 2021-03-25 14:23 UTC by Christopher Wawak
Modified: 2021-10-25 13:11 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Cause: Azure default property Minimum TLS version is 1.0 when creating a storage account. Consequence: Policy check would fail if setting storage account minimum TLS version to 1.2 in organization policies. Fix: Upgraded azurerm provider to support this configuration and configured openshift-installer Azure client to set Minimum TLS version to 1.2 on storage account. Result: Storage account created by the installer is now setting the Minimum TLS version property to 1.2.
Clone Of:
Environment:
Last Closed: 2021-07-27 22:55:38 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github openshift installer pull 4883 0 None open Bug 1943175: azure: set storage account tls default to 1.2 2021-04-27 20:56:30 UTC
Red Hat Knowledge Base (Solution) 5906101 0 None None None 2021-03-25 14:29:07 UTC
Red Hat Product Errata RHSA-2021:2438 0 None None None 2021-07-27 22:56:10 UTC

Internal Links: 1958376

Description Christopher Wawak 2021-03-25 14:23:42 UTC
Version:
4.7.2, also 4.6.something

Platform:
azure

Please specify:
* IPI

What happened?
Customer reports unable to install IPI PRIVATE OpenShift cluster in Azure. This previously worked, but when certain policies were applied to the customer's Azure account, it stopped working.

The installer breaks on:

Error creating Azure Storage Account "clusterpjacy": 
    - {"name":"[Preview]: Storage account public access should be disallowed"
    - "policyDefinition":{"name":"Azure Storage should have the minimal TLS version of 1.2...

What did you expect to happen?
Installer completes successfully.

How to reproduce it (as minimally and precisely as possible)?
openshift-install using attached install-config.yaml

Anything else we need to know?
- Installer log output attached

Comment 3 Matthew Staebler 2021-03-25 15:00:34 UTC
The create of the storage account is also reporting the following.

[Preview]: Storage account public access should be disallowed

Comment 4 Matthew Staebler 2021-03-25 15:01:48 UTC
(In reply to Matthew Staebler from comment #3)
> The create of the storage account is also reporting the following.
> 
> [Preview]: Storage account public access should be disallowed

From the documentation, I would have expected the storage account to have public access disabled by default.

Comment 5 Matthew Staebler 2021-03-25 15:03:05 UTC
@cwawak These are two separate issues. Pick one to address in this BZ and move the other to a new BZ, please.

Comment 6 Christopher Wawak 2021-03-25 15:18:45 UTC
@mstaeble ACK! I will move the SSHd issue.

Comment 7 Christopher Wawak 2021-03-25 15:24:56 UTC
I moved the SSH issue to RHBZ# 1943219.

Comment 8 Etienne Simard 2021-03-25 19:13:26 UTC
Hello Christopher,

I confirm that files uploaded by the installer are set to Private (Public access level setting) in Azure by default when they are created with 4.6 and later.

However, if properties.allowBlobPublicAccess is not disabled, it does not mean that your storage is set to Public. We do not set this parameter with the OpenShift Installer.

~~~
{\"expression\":\"Microsoft.Storage/storageAccounts/allowBlobPublicAccess\",\"expressionKind\":\"Field\",\"operator\":\"Equals\",\"path\":\"properties.allowBlobPublicAccess\",\"result\":\"False\",\"targetValue\":\"false\"}]}
~~~

This is the setting description in the Azure portal: "When allow blob public access is enabled, one is permitted to configure container ACLs to allow anonymous access to blobs within the storage account. When disabled, no anonymous access to blobs within the storage account is permitted, regardless of underlying ACL configurations"


The property properties.minimumTlsVersion is a fairly new property that we do not set with the installer, and this will fail for sure if you try to enforce your policy for TLS version > 1.21 as TLS 1.0 is set by default on the storage account.

~~~
{\"expression\":\"Microsoft.Storage/storageAccounts/minimumTlsVersion\",\"expressionKind\":\"Field\",\"operator\":\"Exists\",\"path\":\"properties.minimumTlsVersion\",\"result\":\"True\",\"targetValue\":\"False\"}]}
~~~


For this to work, the values expected by your policies would need to be set by the client (the Openshift Installer) or match the default setting if not set and these extra configurations are not currently supported in the Installer.

Comment 9 Etienne Simard 2021-03-25 21:13:20 UTC
Thanks for sharing this information with us. We will investigate how to improve the security options/defaults.

Comment 12 To Hung Sze 2021-05-07 19:02:18 UTC
Verified with 4.8.0-0.nightly-2021-05-07-075528.

TLS has been changed to 1.2 for storage account created by the installer:

cluster7lrai    Minimum TLS version: Version 1.2

Each cluster has a storage account created by image-registry which need to be updated as well via BZ1958376

imageregistrytszeaztnnbg       Minimum TLS version: Version 1.0

Comment 14 pawankum 2021-07-01 07:59:10 UTC
(In reply to Etienne Simard from comment #8)
> Hello Christopher,
> 
> I confirm that files uploaded by the installer are set to Private (Public
> access level setting) in Azure by default when they are created with 4.6 and
> later.
> 
> However, if properties.allowBlobPublicAccess is not disabled, it does not
> mean that your storage is set to Public. We do not set this parameter with
> the OpenShift Installer.
> 
> ~~~
> {\"expression\":\"Microsoft.Storage/storageAccounts/allowBlobPublicAccess\",
> \"expressionKind\":\"Field\",\"operator\":\"Equals\",\"path\":\"properties.
> allowBlobPublicAccess\",\"result\":\"False\",\"targetValue\":\"false\"}]}
> ~~~
> 
> This is the setting description in the Azure portal: "When allow blob public
> access is enabled, one is permitted to configure container ACLs to allow
> anonymous access to blobs within the storage account. When disabled, no
> anonymous access to blobs within the storage account is permitted,
> regardless of underlying ACL configurations"
> 
> 
> The property properties.minimumTlsVersion is a fairly new property that we
> do not set with the installer, and this will fail for sure if you try to
> enforce your policy for TLS version > 1.21 as TLS 1.0 is set by default on
> the storage account.
> 
> ~~~
> {\"expression\":\"Microsoft.Storage/storageAccounts/minimumTlsVersion\",
> \"expressionKind\":\"Field\",\"operator\":\"Exists\",\"path\":\"properties.
> minimumTlsVersion\",\"result\":\"True\",\"targetValue\":\"False\"}]}
> ~~~
> 
> 
> For this to work, the values expected by your policies would need to be set
> by the client (the Openshift Installer) or match the default setting if not
> set and these extra configurations are not currently supported in the
> Installer.
Hello Etienne,

I understand that we cannot pass extra parameters in installer, but a customer has the security policies in their environment, they do not allow public access to blob and thus the installer is failing. Can you please let me know any wayaround for this as they cannot change their security policies for installation.



Regards,
Pawan Kumar

Comment 16 errata-xmlrpc 2021-07-27 22:55:38 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (Moderate: OpenShift Container Platform 4.8.2 bug fix and security update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2021:2438

Comment 18 Matthew Staebler 2021-10-25 13:11:48 UTC
*** Bug 2016615 has been marked as a duplicate of this bug. ***


Note You need to log in before you can comment on or make changes to this bug.