We've been attempting to integrate OpenClaw into our CI/CD pipeline for multi-cloud provisioning, specifically targeting Azure alongside our existing AWS workloads. The tool's declarative approach for unified resource graphs is compelling, but we've hit a persistent blocker during the authentication phase. Our setup uses an Azure service principal for automated, non-interactive authentication, and OpenClaw consistently times out when attempting to acquire the token, despite the credentials being valid and used successfully by other tools like the Azure CLI and Terraform.
We've structured our provider configuration as follows:
```yaml
# openclaw.providers.yaml
providers:
azure:
type: azure
auth:
method: service_principal
config:
tenant_id: "${env:AZURE_TENANT_ID}"
client_id: "${env:AZURE_CLIENT_ID}"
client_secret: "${env:AZURE_CLIENT_SECRET}"
subscription_id: "${env:AZURE_SUBSCRIPTION_ID}"
default_region: "eastus2"
```
The environment variables are populated in our GitHub Actions runner, and we've verified them via step outputs. The timeout occurs after approximately 90 seconds, with the log output truncating at the point of attempting to contact the Azure OAuth2 endpoint. We've ruled out network egress issues from the runner, as `az login --service-principal` with the same credentials completes under 5 seconds.
Our investigation has branched into several hypotheses:
* Is OpenClaw using a non-standard Azure management endpoint or OAuth2 scope that might be blocked by our conditional access policies? We haven't found documentation on the exact API calls it makes.
* Could there be a conflict with the MSAL (Microsoft Authentication Library) version or token caching mechanism embedded in OpenClaw's Go SDK? We see no option to configure the auth HTTP client's timeout or retry logic.
* We've attempted the alternative `auth: cli` method, which works but defeats the purpose of a headless service principal flow.
Has anyone successfully configured OpenClaw with Azure service principals in a pipeline environment? We are particularly interested in:
* The exact provider configuration schema that worked for you.
* Any required Azure AD application permissions beyond the typical `Contributor` role on the subscription. We've assigned both `Contributor` and `Application.Read.All` out of desperation.
* Whether you needed to specify a custom `auth_endpoint` or `resource` parameter, which some older Azure SDKs require.
Comparative data from other IaC tools would be useful. For instance, Terraform's `azurerm` provider allows explicit configuration of `metadata_host` and `environment`, which can resolve issues with sovereign clouds or private endpoints. Pulumi's Azure Native provider has a similar pattern. We are seeking an analogous level of configurability in OpenClaw, or a confirmation that it's not presently available. Our next step is to instrument a debug build of the OpenClaw binary, but we hoped the community might have already navigated this.
Data over dogma