fix: restore FIPS-capable runtime base for agent images

[Yetkin Timocin (ytimocin)]

Description of your changes

The hub-agent, member-agent and refresh-token binaries build with CGO_ENABLED=1 GOEXPERIMENT=systemcrypto. That backend dlopen()s libcrypto from the runtime image and, on a node with /proc/sys/crypto/fips_enabled=1, calls SetFIPS(true) — which needs a loadable FIPS provider in that image.

Azure Linux distroless ships one (symcryptprovider.so in /usr/lib/ossl-modules). Debian-based gcr.io/distroless/base ships libcrypto.so.3 with no ossl-modules directory at all, so the call fails and the process panics before main():

panic: opensslcrypto: FIPS mode requested (system FIPS mode) but not available: OpenSSL 3.5.6 7 Apr 2026
crypto/internal/backend.init.0()
	/usr/local/go/src/crypto/internal/backend/openssl_linux.go:39 +0x109

The gcr.io base arrived via the #1338 backport of upstream kubefleet#745 and shipped in v0.18.14, crash-looping (exit 2, CrashLoopBackOff) every hub cluster scheduled onto a FIPS-enabled node and taking Scenario_Fleet_Hubful with it. crd-installer was never switched and stayed healthy.

This restores mcr.microsoft.com/azurelinux/distroless/base:3.0. Only the final FROM changes — :3.0 is a real multi-arch manifest list (linux/amd64 + linux/arm64), so the multi-platform buildx from #745 and the cross-compiling builder from #858 are unaffected.

I have:

• Run make reviewable to ensure this PR is ready for review.

How has this code been tested

• All three images build for linux/amd64,linux/arm64 — amd64 through the cross toolchain, arm64 native, no QEMU.
• Built image's base layer digest matches the Azure Linux amd64 base exactly.
• The resulting hubagent starts normally on both architectures with FIPS forced on; the v0.18.14 image panics with exit 2 under the same conditions.

Reproducible in seconds, no FIPS hardware needed:

docker run --rm --platform linux/amd64 -e GOFIPS=1 mcr.microsoft.com/aks/fleet/hub-agent:v0.18.14  # panics, exit 2
docker run --rm --platform linux/amd64 -e GOFIPS=1 mcr.microsoft.com/aks/fleet/hub-agent:v0.18.13  # starts normally

Special notes for your reviewer

Upstream kubefleet uses gcr.io/distroless here and always has, so this stays an Azure/fleet-only delta that future backports will try to overwrite — the comment on the FROM line records why. Upstream carries the same latent crash (systemcrypto on the providerless base since kubefleet#261); it goes unnoticed there only because FIPS is requested by the node, not the project.

[Copilot]

🟢 Approval recommended

The focused runtime-base correction is consistent across all affected images and supported by multi-architecture FIPS validation.

Pull request overview

Restores FIPS-capable Azure Linux runtime images for systemcrypto-enabled agent binaries.

Changes:

• Replaces Debian distroless with Azure Linux distroless.
• Documents the runtime FIPS-provider requirement.

File summaries

File	Description
docker/hub-agent.Dockerfile	Restores FIPS-capable runtime base.
docker/member-agent.Dockerfile	Restores FIPS-capable runtime base.
docker/refresh-token.Dockerfile	Restores FIPS-capable runtime base.

Review details

• Files reviewed: 3/3 changed files
• Comments generated: 0
• Review effort level: Balanced

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[Copilot]

🟢 Approval recommended

The focused runtime-base changes consistently restore the required FIPS provider across all affected images.

Review details

• Files reviewed: 3/3 changed files
• Comments generated: 0 new
• Review effort level: Balanced

[Chen Yu (michaelawyu)]

LGTM ;) We probably need to do a renaming as Stephane suggested to guard these three files in rebases, but it does not have to be done in this PR.