[Bevan Arps (theunrepentantgeek)]

🤖 TheUnrepentantRobot says:

What this PR does

This PR makes the configured Resource Manager endpoint the common destination boundary for ARM requests, including long-running operation polling, final-result requests and redirects.

• Adds shared HTTPS-origin validation using the hostname and effective port. Hostname normalisation follows Go's HTTP transport, including internationalised names; an omitted port is equivalent to port 443.
• Applies destination checks through the ARM pipeline, including resource-provider registration and SDK clients constructed from the generic client's options.
• Adds client-local redirect checks while preserving existing callbacks, client settings and connection pools.
• Keeps data-plane clients on the original HTTP client, without inheriting ARM-specific destination restrictions.

Polling and result URLs can still use different paths on the configured origin. Rejected destinations flow through existing reconciliation error handling and LRO recovery. Each client uses its selected cloud endpoint, including credential-specific endpoints in multi-environment configurations.

The change also documents the endpoint requirements and adds regression coverage for polling forms, final results, redirects, cloud isolation and data-plane compatibility. There are no new controller settings or changes to resume-token formats, CRDs or YAML samples.

How does this PR make you feel?

More predictable ARM request routing, while keeping data-plane behaviour separate.

Checklist

• this PR contains documentation
• this PR contains tests
• this PR contains YAML Samples

[Bevan Arps (theunrepentantgeek)]

🤖 TheUnrepentantRobot says:

Guide to configured ARM request destinations

The change carries one configured ARM origin through request policies and HTTP redirects, while keeping ARM-specific behaviour out of data-plane clients.

Start here: v2/internal/genericarmclient/generic_client.go:61 - this connects the selected endpoint to both destination-checking mechanisms.

1. An origin is a hostname and effective port, not a URL prefix

What changed: The shared Origin type validates HTTPS endpoints and compares normalised hostnames and numeric ports. Hostname normalisation follows Go's HTTP transport conventions, including IDNA conversion; paths and queries are outside the comparison.

Why it matters: The same definition works across configured clouds and operation URLs without tying acceptance to a particular resource path.

Grok first: v2/internal/httpclient/origin.go:63, v2/internal/genericarmclient/generic_client.go:61

Questions:

1. How does a destination with a different path and explicit port 0443 compare with the same hostname configured without a port?
2. Why does Unicode hostname conversion precede case folding, and what happens if that conversion produces an empty hostname?

2. Validation follows outgoing requests, not resume-token fields

What changed: A per-call policy checks each destination entering the ARM pipeline. Pollers still use the SDK's existing resume-token handling and the client's pipeline for polling and final-result retrieval.

Why it matters: One request-level rule applies across ordinary ARM calls and the different LRO forms without introducing a second interpretation of SDK token formats.

Grok first: v2/internal/genericarmclient/destination_policy.go:26, v2/internal/genericarmclient/generic_client.go:82, v2/internal/genericarmclient/poller.go:32

Questions:

1. How does a resumed operation reach the same destination policy used by ordinary ARM calls?
2. How does Resume update its stored poller and response when polling or final-result retrieval fails, compared with a successful resume?

3. Redirects are a separate HTTP-client control flow

What changed: A copied HTTP client checks redirected destinations around the existing redirect callback, without replacing the underlying transport. Its Do wrapper also gives destination-validation errors a consistent outward form.

Why it matters: Redirects happen within the HTTP client rather than re-entering the SDK pipeline, so they need the same origin rule at that layer.

Grok first: v2/internal/httpclient/redirects.go:19, v2/internal/httpclient/redirects.go:43

Questions:

1. What happens if an existing redirect callback changes an initially acceptable destination to another origin and returns no error?
2. How do a wrapped DestinationError and an unrelated HTTP error emerge differently from Client.Do?

4. ARM and data-plane clients inherit different options

What changed: ARM options carry the destination policy and redirect-checked client into derived SDK clients and the separately constructed resource-provider registration pipeline. Data-plane options retain the original HTTP client while continuing to share cloud, logging, retry, telemetry and user-agent settings.

Why it matters: The ARM boundary follows ARM client construction without changing destination behaviour for connections to other services.

Grok first: v2/internal/genericarmclient/generic_client.go:99, v2/internal/genericarmclient/generic_client.go:137, v2/internal/genericarmclient/policy_register_rp.go:34

Questions:

1. What destination-handling behaviour does a client built from ClientOptions() inherit that one built from DataPlaneClientOptions() does not?
2. Why does installing the redirect-checked transport before constructing the resource-provider registration policy matter for that policy's own requests?

How the rest follows: The tests exercise these same ideas through origin variants, polling and final-result URLs, redirect callbacks, independent cloud clients and data-plane compatibility. The reconciliation test captures existing LRO recovery after a destination error. Documentation explains the endpoint contract, the existing IDNA dependency becomes direct, and the formatting, Gomega and named-table edits make those behaviours easier to read.

[Copilot]

🔵 Needs a closer look

The security-sensitive routing boundary needs human validation, and a reconciliation recovery issue remains unresolved.

1 open issue

• Clear rejected backup-instance poll token to restart sync · New

What changed in this PR

Restricts Azure Resource Manager requests to the configured HTTPS origin while keeping data-plane traffic independent.

Changes:

• Adds origin validation to ARM pipelines and redirects.
• Preserves shared HTTP settings without applying ARM restrictions to data-plane clients.
• Documents endpoint requirements and adds regression coverage.

File	Description
v2/​internal/​reconcilers/​arm/​destination_failure_test.go	Tests generic reconciliation recovery.
v2/​internal/​httpclient/​redirects.go	Guards redirected destinations.
v2/​internal/​httpclient/​redirects_test.go	Tests redirect restrictions and compatibility.
v2/​internal/​httpclient/​origin.go	Validates HTTPS origins.
v2/​internal/​httpclient/​origin_test.go	Tests origin normalization and rejection.
v2/​internal/​genericarmclient/​generic_client.go	Integrates guards and separates data-plane transport.
v2/​internal/​genericarmclient/​destination_transport_test.go	Checks transport hostname behavior.
v2/​internal/​genericarmclient/​destination_sdk_test.go	Tests SDK enforcement and cloud isolation.
v2/​internal/​genericarmclient/​destination_poller_test.go	Tests polling and final-result destinations.
v2/​internal/​genericarmclient/​destination_policy.go	Rejects disallowed pipeline destinations.
v2/​internal/​genericarmclient/​destination_policy_test.go	Tests early rejection and registration redirects.
v2/​internal/​genericarmclient/​data_plane_client_options_test.go	Verifies data-plane redirect compatibility.
v2/​go.mod	Makes hostname-normalization dependency direct.
docs/​hugo/​content/​guide/​aso-controller-settings-options.md	Documents endpoint restrictions.

_{Review effort: Balanced}

[Matthew Christopher (matthchr)]

🤖 net.ParseIP(host) is only used as a validity check here; its canonical representation is discarded. A configured origin such as [2001:db8::1] will therefore reject [2001:0db8:0:0:0:0:0:1], even though both literals identify the same IPv6 address. Please normalize parsed IP hosts with ip.String() before storing/comparing them, and cover compressed versus expanded IPv6 forms.

[Matthew Christopher (matthchr)]

I think what it is trying to say here is that the above two IPs will not compare as equal in this code.

Here's a more detailed breakdown from my agent after I asked it to explain more:

This is a false rejection, not a security bypass. The validator can reject two URLs that Go ultimately sends to the same IP address.

Current behavior

originOf() extracts the hostname and checks IPv6 validity:

Go

host := authority.Hostname()

if strings.Contains(host, ":") && net.ParseIP(host) == nil {
    return Origin{}, false
}

But afterward it stores the original textual representation:

Go

return Origin{
    host: strings.ToLower(host),
    port: strconv.Itoa(n),
}, true

Origin.Validate() compares the structs directly:

Go

candidate == o

That means the host strings must be identical.

Why that fails for IPv6

IPv6 permits multiple textual representations of the same 128-bit address:

Plain text

2001:db8::1
2001:0db8:0:0:0:0:0:1
2001:0DB8:0000:0000:0000:0000:0000:0001

All three represent the same address. net.ParseIP() successfully parses each, and comparing the parsed addresses would show they are equal. However, lowercasing only fixes the third form’s uppercase letters; it does not remove leading zeros or expand/compress zero groups.

For example:

Go

allowed, _ := NewOrigin("https://[2001:db8::1]")

err := allowed.Validate(
    mustParseURL("https://[2001:0db8:0:0:0:0:0:1]/operations/123"))

Internally, the comparison becomes approximately:

Go

Origin{
    host: "2001:db8::1",
    port: "443",
} == Origin{
    host: "2001:0db8:0:0:0:0:0:1",
    port: "443",
}

That is false even though both URLs reach the same address.

When it could affect ASO

This requires a configured Resource Manager endpoint using an IPv6 literal rather than a DNS name, for example:

Plain text

https://[2001:db8::1]

It then requires ARM, a custom gateway, a redirect, or an LRO resume token to express that address differently. The request would be rejected with DestinationError, even though it stays on the same endpoint.

Possible consequences include:

• LRO polling stops.

• A final-result request fails.

• A redirect is rejected.

• A persisted resume token repeatedly fails after an endpoint-format change.

Public Azure endpoints such as management.azure.com are unaffected because they use DNS names. The concern is primarily custom clouds, private gateways, and testing infrastructure.

Why normalization is safe

Canonicalization would not permit another server or DNS alias. It only makes different encodings of the same IP address compare equal.

A suitable implementation could use net/netip, whose Addr.String() returns a canonical representation:

Go

if strings.Contains(host, ":") {
    addr, err := netip.ParseAddr(host)
    if err != nil || !addr.Is6() {
        return Origin{}, false
    }

    host = addr.String()
}

Both inputs would then normalize to:

Plain text

2001:db8::1

Tests should cover at least:

Go

"https://[2001:db8::1]"
"https://[2001:0db8:0:0:0:0:0:1]"
"https://[2001:0DB8:0000:0000:0000:0000:0000:0001]"

IPv4-mapped IPv6 addresses should also have an explicit test because different normalization APIs may either preserve the mapped IPv6 form or collapse it to dotted IPv4.

Priority assessment

Medium reflects the impact—requests can be permanently blocked—but the trigger is uncommon. If literal IPv6 custom ARM endpoints are not an expected supported configuration, Low would also be defensible. It is not a vulnerability because the current behavior is stricter than necessary; it is a compatibility and availability issue.

[Matthew Christopher (matthchr)]

Approved. Clarified the one remaining comment but feel free to ignore it OR if you think it's worth fixing, fix in a followup PR

[Matthew Christopher (matthchr)]

I think what it is trying to say here is that the above two IPs will not compare as equal in this code.

Here's a more detailed breakdown from my agent after I asked it to explain more:

This is a false rejection, not a security bypass. The validator can reject two URLs that Go ultimately sends to the same IP address.

Current behavior

originOf() extracts the hostname and checks IPv6 validity:

Go

host := authority.Hostname()

if strings.Contains(host, ":") && net.ParseIP(host) == nil {
    return Origin{}, false
}

But afterward it stores the original textual representation:

Go

return Origin{
    host: strings.ToLower(host),
    port: strconv.Itoa(n),
}, true

Origin.Validate() compares the structs directly:

Go

candidate == o

That means the host strings must be identical.

Why that fails for IPv6

IPv6 permits multiple textual representations of the same 128-bit address:

Plain text

2001:db8::1
2001:0db8:0:0:0:0:0:1
2001:0DB8:0000:0000:0000:0000:0000:0001

All three represent the same address. net.ParseIP() successfully parses each, and comparing the parsed addresses would show they are equal. However, lowercasing only fixes the third form’s uppercase letters; it does not remove leading zeros or expand/compress zero groups.

For example:

Go

allowed, _ := NewOrigin("https://[2001:db8::1]")

err := allowed.Validate(
    mustParseURL("https://[2001:0db8:0:0:0:0:0:1]/operations/123"))

Internally, the comparison becomes approximately:

Go

Origin{
    host: "2001:db8::1",
    port: "443",
} == Origin{
    host: "2001:0db8:0:0:0:0:0:1",
    port: "443",
}

That is false even though both URLs reach the same address.

When it could affect ASO

This requires a configured Resource Manager endpoint using an IPv6 literal rather than a DNS name, for example:

Plain text

https://[2001:db8::1]

It then requires ARM, a custom gateway, a redirect, or an LRO resume token to express that address differently. The request would be rejected with DestinationError, even though it stays on the same endpoint.

Possible consequences include:

• LRO polling stops.

• A final-result request fails.

• A redirect is rejected.

• A persisted resume token repeatedly fails after an endpoint-format change.

Public Azure endpoints such as management.azure.com are unaffected because they use DNS names. The concern is primarily custom clouds, private gateways, and testing infrastructure.

Why normalization is safe

Canonicalization would not permit another server or DNS alias. It only makes different encodings of the same IP address compare equal.

A suitable implementation could use net/netip, whose Addr.String() returns a canonical representation:

Go

if strings.Contains(host, ":") {
    addr, err := netip.ParseAddr(host)
    if err != nil || !addr.Is6() {
        return Origin{}, false
    }

    host = addr.String()
}

Both inputs would then normalize to:

Plain text

2001:db8::1

Tests should cover at least:

Go

"https://[2001:db8::1]"
"https://[2001:0db8:0:0:0:0:0:1]"
"https://[2001:0DB8:0000:0000:0000:0000:0000:0001]"

IPv4-mapped IPv6 addresses should also have an explicit test because different normalization APIs may either preserve the mapped IPv6 form or collapse it to dotted IPv4.

Priority assessment

Medium reflects the impact—requests can be permanently blocked—but the trigger is uncommon. If literal IPv6 custom ARM endpoints are not an expected supported configuration, Low would also be defensible. It is not a vulnerability because the current behavior is stricter than necessary; it is a compatibility and availability issue.