Support fetching from protected assets with Azure Storage

[travier]

Feature Request

Environment

What hardware/cloud provider/hypervisor is being used to run Ignition?

Azure

Desired Feature

Support fetching the Ignition config from an Azure Storage blob that is protected in access by a managed identity. See: https://learn.microsoft.com/en-us/entra/identity/managed-identities-azure-resources/tutorial-linux-managed-identities-vm-access?pivots=identity-linux-mi-vm-access-storage

See:

• https://issues.redhat.com/browse/RFE-1773
• https://issues.redhat.com/browse/COS-3141

Initial implementation in: #1923

Details that remain to be figured out:

• Does this changes the behavior for existing / unprotected assets?
• Should this be a spec bump? (needed if this changes the current behavior)
• How should we document that support if we want to keep this as is?

The main difference here (compared to AWS S3 support for example) is that this is not using a special URI but regular HTTP URLs, so there is no immediate way of differentiating support / request for that feature.

Tracker for testing: coreos/fedora-coreos-tracker#1871

Other Information

See:

• Documentation tracking issue: Document support for Azure Blob sources #2008
• In progress documentation: provisioning azure: add remote ign ex on private azure blob fedora-coreos-docs#702

[jlebon]

The code as written currently hard fails if e.g. it fails to get Azure credentials. If those URLs could have been used in the past (as e.g. public read), then spec gating or not, we should have any failure in the new path be at most a warning and have Ignition still fallback to anonymous HTTP fetches.

In fact, I think just doing that fallback should be sufficient to make this not spec gating.

[prestist]

@jlebon Ah, yeah that makes sense, okay I can add that change here shortly and will link a pr.

[prestist]

@jlebon I have added the fallback logic to this followup pr with documentation. #2012