Bug 2020216

This would ultimately be a docs change, but I want to send it to the Installer folks as this change might be an implementation detail they would have to consider.

My understanding is that the default for the storage container is to have public access off. What changes would you expect in the documentation?

~~~~
$ az storage container create --help | grep Command -A 5
Please let us know how we are doing: https://aka.ms/azureclihats
Command
    az storage container create : Create a container in a storage account.
        By default, container data is private ("off") to the account owner. Use "blob" to allow
        public read access for blobs. Use "container" to allow public read and list access to the
        entire container. You can configure the --public-access using `az storage container set-
        permission -n CONTAINER_NAME --public-access blob/container/off`.
~~~~

In the documentation which I mentioned in the description there is guidance like below:
```
Create a blob storage container and upload the generated bootstrap.ign file:


$ az storage container create --name files --account-name ${CLUSTER_NAME}sa --account-key ${ACCOUNT_KEY} --public-access blob

$ az storage blob upload --account-name ${CLUSTER_NAME}sa --account-key ${ACCOUNT_KEY} -c "files" -f "<installation_directory>/bootstrap.ign" -n "bootstrap.ign"
```

So the storage container blob with the bootstrap.ign file is with public read access. 
I'm not sure if only change in the documentation is needed. Maybe the installation procedure should be corrected as well to address this issue.
It's Installer team decision how to address this problem. Definitely from the Product Security Team perspective it must be corrected.

Oh, I missed the use of the `--public-access blob` flag. I swear that I looked at that command a number of times.

I agree that it should be fixed. That is strictly a docs bug then. As far as I can tell, that command is not sourced from the installer repo.

@Matthew This command is pulled from the installer dev doc for Azure UPI [1]. Can we simply drop the `--public-access blob` flag from our documentation to fix this security issue? Not sure what the original requirement was for that.

[1] https://github.com/openshift/installer/blob/master/docs/user/azure/install_upi.md#upload-the-bootstrap-ignition

Ah, OK. I'll put this BZ back on the installer team. I think if we remove the public access to the blob, then the URL in the bootstrap ignition stub needs to be changed to include a SAS token as well.

based on my test 
"az storage container create --name files --account-name ${CLUSTER_NAME}sa --account-key ${ACCOUNT_KEY} --public-access blob"
"--public-access blob" can not be removed 

without the "--public-access blob", bootstrap.json fail to deployed.

az deployment group create -g $RESOURCE_GROUP   --template-file "04_bootstrap.json" --parameters bootstrapIgnition="$BOOTSTRAP_IGNITION" --parameters baseName="$INFRA_ID"

 {\r\n        \"code\": \"OSProvisioningTimedOut\",\r\n        \"message\": \"OS Provisioning for VM 'maxu2020216-g92js-bootstrap' did not finish in the allotted time.

updated docs/user/azure/install_upi.md in https://github.com/openshift/installer/pull/5457

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.10.3 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-2022:0056