Hey folks, has anyone else run into the Azure integration just... skipping subscriptions? I've been wrestling with this for two days now.
I'm managing a multi-tenant Azure setup with Terraform, and I've got the Lacework provider configured to pull in data from several subscriptions. My `main.tf` looks standard:
```hcl
provider "lacework" {
alias = "azure_ad"
}
resource "lacework_integration_azure_al" "subscription_scan" {
name = "azure-al-${var.subscription_name}"
tenant_id = var.tenant_id
credentials {
client_id = var.client_id
client_secret = var.client_secret
}
subscription_id = var.subscription_id
enabled = true
}
```
The module loops over a list of subscriptions. Most integrate fine, but one or two just never show up in the Lacework console under "Resources." No errors during `terraform apply`—the provider returns success. I've triple-checked:
* The Service Principal has `Contributor` on the missing subscriptions.
* The `subscription_id` is definitely correct in the Terraform variables.
* There are no obvious API throttling logs.
It feels like a silent failure. Before I dive deeper with support, I wanted to check if this is a known quirk. Maybe related to recent Azure API changes? I'm on provider version `~> 1.0`.
If you've seen this, did you find a workaround? I'm considering adding an explicit `time_sleep` resource between integrations to see if it's a race condition.
Yeah, ran into something similar last month. The apply succeeds but the resource just... ghosts you. For me, it was a permissions timing issue - the service principal was added *too* recently before the Terraform run. Azure's internal propagation lagged.
Try running a manual test of the exact credentials against the Azure Management API for the missing sub, maybe with Postman. That bypassed Terraform and showed me the real error - an unexpected "reader" role assignment overriding contributor at the management group level.
Silent failures are the worst. Did you check Activity Logs in the Azure portal for those specific subscriptions during the apply window? Sometimes the deny event is logged there, not in Lacework.
Absolutely! The permissions timing issue can be super sneaky. I've seen the same thing - service principal replication delays cause silent Terraform success but functional failure.
A trick that helped me was adding a deliberate `time_sleep` resource after creating the service principal and role assignment, before the Lacework integration runs. Just a 60-90 second wait can save hours of debugging 😅
> Try running a manual test of the exact credentials against the Azure Management API
This is golden advice. I usually use the Azure CLI for a quick test: `az rest --method get --uri "https://management.azure.com/subscriptions/{sub-id}?api-version=2020-01-01"`. If that fails, you know it's an Azure IAM problem, not a Lacework config issue.
Infrastructure as code is the only way
Oh yeah, that silent success thing is so frustrating! I'm still pretty new to this Azure-Lacework setup myself, but I hit a similar wall last week. For me, it turned out the service principal didn't have the **Reader** role on the subscription, only Contributor. Apparently Lacework needs both for some of its resource listing calls.
What version of the Lacework provider are you on? I saw some chatter in another thread about a bug in version 1.x where the integration would succeed but not actually register if the subscription name had certain special characters, even if they were allowed. Might be worth checking the console for any oddly named subs?
rookie
Yeah, the Reader role tip is spot on. Been there, done that, got the overpriced Azure t-shirt.
But blaming special characters? That's a real subscription-al hazard.
Check your provider logs with debug mode if you can. Sometimes the API error is swallowed by the happy-path "create" logic. It'll tell you if it's a permissions handshake problem or something weirder.
Deploy with love
Absolutely. The swallowed API error pattern is the real culprit here, not the permissions. The provider's "success" status often just means the HTTP call to Lacework's own API for the *integration record* succeeded, not that the subsequent Azure handshake did.
Debug logs are critical. But even then, you need to look for the *second* API call, not the first. I've seen the initial POST return a 200, but the provider's internal "test" call to validate Azure connectivity fails silently and never bubbles up to Terraform's output. Makes you chase ghosts in IAM all day.
That's why I always run a separate `lacework integration show ` right after apply. The JSON response sometimes has an "AZURE_AUTH_ERROR" buried in a status field you'd never see in the plan/apply output. Annoying, but it cuts the debug time in half.
Metrics or it didn't happen.