fix(azure): sign build-context blob requests with the storage account's shared key - #927
Merged
Conversation
added 4 commits
August 25, 2026 10:24
…'s shared key The Azure Container Registry build service reached the build-context container with azblob.NewClientWithNoCredential, on a comment claiming the simulator does not enforce storage bearer auth — no longer true, so the client would be refused at the next simulator pin bump, and it was never right against a sovereign cloud either. The client now reads the account key through the Azure Resource Manager (ListKeys, the way an administrator reads it) and signs with NewSharedKeyCredential, which works over plain HTTP where azblob rejects bearer tokens — the same code against the simulator and the real cloud, differing only in coordinates. A new test provisions a storage account through ARM against the pinned simulator and round-trips a blob through the signed client. The advertised blob host is a per-account name under .shim.localhost that a deployment's DNS resolves (dnsmasq in the Linux harness, systemd-resolved on CI); macOS cannot map it without root — the documented host-capability skip. Linux never skips.
… Route 53 DNS a free port The pre-push freshness gate found 39 drifts: AWS SDK for Go v2 service modules across aws-common/ecs/lambda/tests, cloud.google.com/go/storage and gRPC across the Google Cloud backends, cloudbuild in gcp-common, testify in the ECS terraform test module, and the docker/setup-buildx-action pin. All upgraded modules build and their tests pass. The ECS terraform harness started the simulator without SIM_DNS_PORT, so the Route 53 DNS listener bound the default :5353 — mDNS, which desktop browsers hold open — and the simulator refused to start on any host with a browser running. The harness now hands it a free port, the same way the sockerless-cloud test harnesses do.
The upgrade moved shared dependencies (gRPC, protobuf, genproto, x/net) that modules beyond the freshness-flagged ones consume, and a conflicted pre-commit stash rollback left several go.sum files without entries for them — CI's build jobs failed on the missing sums. Every module is tidied and builds with GOWORK=off; the freshness check stays clean.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The consumer follow-up recorded when the simulator started enforcing storage authorization: the Azure Container Registry build service reached the build-context blob container with
azblob.NewClientWithNoCredential, on a comment claiming the simulator "does not enforce storage bearer auth" — no longer true, so the client would be refused at the next simulator pin bump, and it was never right against a sovereign cloud either.The fix
ensureBlobClientnow reads the storage account's key through the Azure Resource Manager (ListKeys— the way an administrator reads it, on the accounts client the service already holds) and builds the blob client withNewSharedKeyCredential. Shared-key signing works over plain HTTP, where azblob rejects bearer tokens — the same code against the simulator and the real cloud, differing only in coordinates.Proof
A new test in
backends/azure-commonprovisions a storage account through ARM against the pinned simulator, resolves the advertised blob endpoint, and round-trips a blob through the signed client. The blob host is a per-account name under.shim.localhostthat a deployment's DNS resolves — dnsmasq in the Linux harness, systemd-resolved on CI; macOS cannot install that mapping without root, the documented host-capability skip (Linux never skips).Bundled
docker/setup-buildx-action). Every upgraded module builds and its tests pass.SIM_DNS_PORT, so the Route 53 DNS listener bound the default:5353— mDNS, held open by desktop browsers — and the simulator refused to start on hosts with a browser running. The harness now hands it a free port, like the sockerless-cloud harnesses do.