You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[BUG] Azure cloud blocking loads only the first service tag, so almost every Azure range stays unblocked #77
Azure's ServiceTags document is a list of ~100 service-tag objects, each with
its own addressPrefixes. Only values[0] is read, so block_cloud_providers={"Azure"} builds its block set from one tag and fails
open for the rest, silently. The AWS and GCP fetchers iterate correctly.
A three-tag stand-in for the real document:
3 service tags in the document -> 1/3 prefixes loaded
Whichever tag happens to be first in the published file is the only one that
ever blocks, and that ordering is Microsoft's to change. Meanwhile the
operator's config and the status route both say Azure blocking is on.
Reproduced: a three-tag stand-in loads 1/3 of the prefixes in both the async and sync trees, and the [0] goes back to the first commit.
One correction on the fix: unioning every tag is not what we want. Microsoft's ServiceTags file bundles roughly 100 tags, including Microsoft 365 and Exchange control-plane ranges, so a blind union over-blocks well beyond "Azure compute". The AWS fetcher already filters to the umbrella entry (service == "AMAZON"); the Azure fix filters values to the AzureCloud tag the same way. We also checked the ordering claim: AzureCloud is not values[0] in the real document (ActionGroup sorts first), so the current code was never even loading the aggregate.
Fixed in 3.14.0, with a multi-tag fixture so the single-tag test shape cannot hide this again.
Activity
rennf93 commentedon Aug 25, 2026
Thanks @RomanPszonka for opening the issue! By @rennf93's directive:
Reproduced: a three-tag stand-in loads 1/3 of the prefixes in both the async and sync trees, and the
[0]goes back to the first commit.One correction on the fix: unioning every tag is not what we want. Microsoft's ServiceTags file bundles roughly 100 tags, including Microsoft 365 and Exchange control-plane ranges, so a blind union over-blocks well beyond "Azure compute". The AWS fetcher already filters to the umbrella entry (
service == "AMAZON"); the Azure fix filtersvaluesto theAzureCloudtag the same way. We also checked the ordering claim:AzureCloudis notvalues[0]in the real document (ActionGroupsorts first), so the current code was never even loading the aggregate.Fixed in 3.14.0, with a multi-tag fixture so the single-tag test shape cannot hide this again.
rennf93 commentedon Aug 26, 2026
Shipped in guard-core 3.14.0 (PyPI), merged in #82 (500d4ef).
The Azure cloud-IP fetch now loads the
AzureCloudservice tag by name instead of whichever tag sorts first.