I've been running Tenable Cloud Security (formerly Tenable.cs) in our Azure environment for several months, primarily to benchmark its scan duration and resource consumption. Recently, our CI/CD pipeline started failing during the storage account scanning phase with a persistent permissions error.
The error consistently occurs when the scanner attempts to enumerate containers within a specific set of storage accounts. The service principal used by Tenable has the `Storage Blob Data Reader` role assigned at the subscription level, which *should* be sufficient according to the documentation. However, the logs indicate:
```
ERROR: Failed to list blob containers for account 'stgbenchmarkdata01':
StatusCode=403, StatusDescription=AuthorizationFailed,
ErrorMessage=This request is not authorized to perform this operation.
```
My initial hypothesis was role assignment propagation delay, but the issue persists after 72 hours. I've verified the following:
* The service principal's Object ID is correctly listed in the Role Assignments for the subscription.
* No Deny Assignments are present on the subscription, resource group, or storage accounts themselves.
* The storage accounts are standard GPv2, not secured with firewall rules that would block the scanner's IP.
I then ran a manual test using `az rest` to simulate the permission check, using the same API call I believe the scanner uses:
```bash
az rest --method get --uri "https://management.azure.com/subscriptions//resourceGroups//providers/Microsoft.Storage/storageAccounts//blobServices/default/containers?api-version=2023-01-01"
```
This command succeeded when run under my identity, but I need to validate it under the service principal context. Has anyone else performed a similar benchmark or troubleshooting step and encountered a mismatch between the documented required permissions (`Storage Blob Data Reader`) and what is actually needed at the management plane versus data plane?
Potential variables I'm considering:
* Is the scanner querying the management API (which might require `Reader` or a specific storage *management* role) versus the data plane API?
* Could there be a condition in the role assignment (like MFA requirement) that the scanner cannot satisfy?
* Are there new, container-specific permissions or Azure RBAC changes that haven't been reflected in the scanner's logic?
I'll be conducting further tests by assigning `Contributor` temporarily to isolate if it's a scope/role issue, and will update with the performance impact (scan time delta) once resolved. Any data points from your own environments would be helpful.
Numbers don't lie