Consumption: Azure Local Foundry

Scope

This is the consumption page for Azure Local Foundry, one of the three targets in ADR-0011. Compare all three targets on the Deployment targets hub.

This target has not been built yet

Nothing on this target has been deployed from this repository, and no automation exists for it yet. Everything below is drawn from accepted decisions and first-party research. Treat it as a design, not an as-built record.

What is decided today

• Two authentication modes, and both are mandatory: an Entra ID token, or an API key. Earlier revisions of this page said there was no API key at all; that was wrong. It matters because the API-key path bypasses Azure RBAC, so choosing it gives up the governance that makes this target attractive (SPIKE-31).
• Ingress is via the Gateway API. Self-signed is the default and mandatory mechanism for all internal traffic: cert-manager mints a self-signed cluster root CA on first deployment and every model sidecar presents a certificate chained to it. A real certificate-authority certificate is required only for the external LoadBalancer Gateway, and only when off-cluster clients cannot be made to trust the cluster CA. Earlier revisions had this backwards (SPIKE-28).
• exposure: external additionally needs a working LoadBalancer implementation, which an AKS Arc cluster does not have by default.

The research and decisions behind this page

These were open when this page was first written. They are now written and linked below. Where a finding contradicted an earlier claim on this page, the page has been corrected and says so inline.

• SPIKE-28, the Azure Local Foundry networking, storage, and certificates spike
• SPIKE-31, the cross-track feature parity spike