Fix: storage account 403 error when creating new tre env

[ShakutaiGit]

Resolves #4405

What is being addressed

• Ensuring role propagation before execution: The script now properly waits for both Storage Account Contributor and Storage Blob Data Contributor roles to be assigned before attempting storage operations.
• Refactoring role assignment check: Instead of checking a single role, the script now verifies both roles are assigned before proceeding, reducing failures due to role propagation delays.

Testing:

• branch before the change (with the issue) https://github.com/microsoft/AzureTRE/actions/runs/13544133660
• test of a new branch from the PR branch (after the change in the PR) https://github.com/microsoft/AzureTRE/actions/runs/13552936616

[github-actions]

Unit Test Results

0 tests   0 ✅  0s ⏱️
0 suites  0 💤
0 files    0 ❌

Results for commit 4c26cde.

♻️ This comment has been updated with latest results.

[ShakutaiGit]

/test

[github-actions]

🤖 pr-bot 🤖

🏃 Running tests: https://github.com/microsoft/AzureTRE/actions/runs/13545863577 (with refid ecb751e8)

(in response to this comment from @ShakutaiGit)

[ShakutaiGit]

/test

[github-actions]

🤖 pr-bot 🤖

🏃 Running tests: https://github.com/microsoft/AzureTRE/actions/runs/13547308284 (with refid ecb751e8)

(in response to this comment from @ShakutaiGit)

[ShakutaiGit]

/test

[github-actions]

🤖 pr-bot 🤖

🏃 Running tests: https://github.com/microsoft/AzureTRE/actions/runs/13553941503 (with refid ecb751e8)

(in response to this comment from @ShakutaiGit)

[ShakutaiGit]

/test

[github-actions]

🤖 pr-bot 🤖

🏃 Running tests: https://github.com/microsoft/AzureTRE/actions/runs/13559362952 (with refid ecb751e8)

(in response to this comment from @ShakutaiGit)

[marrobi]

Couple of comments. Thanks for looking into making this more robust.

[marrobi]

Suggestion from copilot, not tested, but makes sense to have a timeout of some sort...

# Function to check if the role assignments exist
check_role_assignments() {
  local roles
  roles=$(az role assignment list \
    --assignee "$USER_OBJECT_ID" \
    --scope "/subscriptions/$ARM_SUBSCRIPTION_ID/resourceGroups/$TF_VAR_mgmt_resource_group_name/providers/Microsoft.Storage/storageAccounts/$TF_VAR_mgmt_storage_account_name" \
    --query "[?roleDefinitionName=='Storage Blob Data Contributor' || roleDefinitionName=='Storage Account Contributor'].roleDefinitionName" --output tsv)
  
  if [[ $roles == *"Storage Blob Data Contributor"* && $roles == *"Storage Account Contributor"* ]]; then
    echo "both"
  fi
}

# Wait for the role assignment to be applied with a timeout
echo -e "\n\e[34m»»» ⏳ \e[96mWaiting for role assignment to be applied\e[0m..."
timeout=300  # 5 minutes timeout
start_time=$(date +%s)

while [ -z "$(check_role_assignments)" ]; do
  echo "Waiting for role assignment..."
  sleep 10
  current_time=$(date +%s)
  elapsed_time=$((current_time - start_time))
  if [ $elapsed_time -ge $timeout ]; then
    echo "ERROR: Timeout waiting for role assignments."
    exit 1
  fi
done
echo "Role assignment applied."

[marrobi]

Why do we need to sleep if we are retrying below?

[marrobi]

Did you work out why this is required? I thought the object ID that creates the storage account should have sufficient permissions?