https://docs.redhat.com/en/documentation/openshift_container_platform/4.17/html/backup_and_restore/oadp-application-backup-and-restore#configuring-oadp-with-azure

We need to double-check these docs

User has raised an issue: "We’ve encountered a challenge related to authentication: Red Hat Doc has advised that both a service principal and storage access keys are required to access the storage account.

This is unexpected for the customer, as in most scenarios they've worked with, either a service principal (or managed identity) or storage access keys and they feel this alone is sufficient.

Customer would like to know the reason for enabling both of them together:

```
AZURE_CLIENT_ID=<azure_client_id>
AZURE_CLIENT_SECRET=<azure_client_secret>
AZURE_STORAGE_ACCOUNT_ACCESS_KEY=<azure_storage_account_access_key>
```

only the below parameter should works as expected:

```
AZURE_SUBSCRIPTION_ID= <azure_subscription_id>
AZURE_TENANT_ID=<azure_tenant_id>
AZURE_CLIENT_ID=<azure_client_id>
AZURE_CLIENT_SECRET=<azure_client_secret>
AZURE_RESOURCE_GROUP=<azure_resource_group>
AZURE_CLOUD_NAME=<azure_cloud_name>

```
The following two examples have been tested by QE:

Without  storage account access key(Service Principal) :

AZURE_SUBSCRIPTION_ID=53b8f551-f0fc-4bea-8cba-6d1fefd54c8a

AZURE_TENANT_ID=6047c7e9-b2ad-488d-a54e-dc3f6be6a7ee

AZURE_CLIENT_ID=5c9d067d-92af-4e93-b18a-bb7a8cf94088

AZURE_CLIENT_SECRET=<fill this value>

AZURE_RESOURCE_GROUP=oadp-122041-4vq7r-rg

AZURE_CLOUD_NAME=AzurePublicCloud

With storage account access key :

AZURE_STORAGE_ACCOUNT_ACCESS_KEY= <>

AZURE_CLOUD_NAME=AzurePublicCloud

For more details, see the slack thread - https://redhat-internal.slack.com/archives/C0144ECKUJ0/p1750104328448569