Exposing a Model Context Protocol (MCP) server running on Azure Kubernetes Service (AKS) for team-wide or external use requires a robust production setup. While local port-forwarding works during early development, a production-grade infrastructure demands public domain routing, automated TLS certificate lifecycles, and identity-based access control.
By combining the Kubernetes Gateway API, cert-manager, Azure Workload Identity, and Microsoft Entra ID, you can deploy an internet-facing MCP server that remains completely secure without managing long-lived secrets or manual port forwards.
Gateway API & ListenerSet Routing
Connecting to an MCP server directly over HTTPS requires defining an ingress point using the Kubernetes Gateway API. Utilizing a ListenerSet resource allows you to attach dedicated listener configurations—specifically for HTTPS on port 443—directly to an existing Gateway infrastructure.
An accompanying HTTPRoute maps external incoming requests on your domain to the target MCP service running inside the cluster on port 8000. This decoupled architecture separates infrastructure management from application routing, ensuring clean traffic handling.
Automated TLS via Cert-Manager and Azure Workload Identity
To serve traffic over HTTPS without managing static SSL/TLS certificates, cert-manager automates issuance and renewal through Let’s Encrypt.
Zero-Secret DNS-01 Validation
To validate domain ownership for certificate requests, cert-manager uses the ACME DNS-01 challenge against Azure DNS. Rather than storing sensitive Azure credentials in Kubernetes secrets, the authentication relies on Azure Workload Identity:
- User-Assigned Managed Identity: Created in Azure and assigned the
DNS Zone Contributorrole scoped directly to your Azure DNS zone. - Federated Credentials: Linked between the Azure Managed Identity and the
cert-managerKubernetes service account using your cluster’s OIDC issuer URL. - ClusterIssuer Configuration: A
ClusterIssuerresource points to Let’s Encrypt and uses the managed identity’s Client ID to interact with Azure DNS seamlessly.
When a new certificate is required, cert-manager dynamically creates the necessary TXT records in Azure DNS to satisfy the ACME challenge, receives the signed TLS certificate, and populates the secret referenced by your Gateway API ListenerSet. Automatic renewals trigger 30 days prior to expiration.
Entra ID Authentication & Remote Helm Configuration
Because the endpoint is publicly accessible, access must be restricted to authenticated users.
To support authentication over a custom HTTPS domain:
- App Registration Update: Add the external OAuth callback URL (
https://<your-domain>/oauth/callback) to your Entra ID App Registration redirect URIs. - Helm Values Update: Upgrade the MCP Helm release to accept the new external domain name in its allowed hosts configuration, alongside the local Visual Studio Code callback port.
Verifying Remote Access in Visual Studio Code
With HTTPS and Entra ID configured, Visual Studio Code connects directly to the remote domain endpoint. When initiating a connection:
- VS Code triggers an OAuth login prompt directing you to your custom domain.
- Entra ID enforces user authentication and Multi-Factor Authentication (MFA).
- Upon successful login, VS Code receives an authorization token and establishes a secure channel to the MCP server.
Wrapping Up
Transitioning from local port-forwarding to a public-facing infrastructure powered by the Gateway API, cert-manager, Azure Workload Identity, and Entra ID turns a developer experiment into an enterprise-ready platform utility. This architecture gives your engineering team friction-free remote access directly from Visual Studio Code while maintaining strict zero-trust access control and zero secret-management overhead.
You can find all the code sample on GitHub.
This post was AI-generated based on the transcript of the video “Production TLS for AKS MCP - Cert-Manager & Envoy Gateway API”.
Comments powered by Disqus.