Skip to content

Helm on private AKS

Use this guide when the AKS API server is private. User traffic may still enter through a public Application Gateway; only operator access to kubectl / helm is constrained.

Operator host requirements

You need a machine that can:

  1. Reach the private API endpoint (VPN, ExpressRoute, or jump VM in the cluster VNet / peered VNet)
  2. Authenticate to Azure (az login or managed identity)
  3. Hold or fetch kubeconfig

Example on a jump VM after Azure CLI login:

az aks get-credentials \
  --resource-group <rg> \
  --name <aks-name> \
  --overwrite-existing

kubectl get nodes

If get-credentials writes a private FQDN, run Helm on that same network path. Do not expect a laptop outside the VNet to work without VPN.

Install pattern (same for every chart)

# Example: observability first
helm upgrade --install ams-observability ./ams-helm-observability-stack \
  --namespace observability \
  --create-namespace \
  -f providers/azure/release/values.yaml

# Then Keycloak, modules, ingress, adapters…

Tips:

  • Pin chart versions / image tags in release values.
  • Prefer helm upgrade --install for idempotent re-runs.
  • Use --wait --timeout 20m when you want Helm to block until resources settle.

Private cluster specifics

Topic Guidance
Image pulls Ensure nodes can reach ACR (private endpoint or service endpoint + PE DNS)
Key Vault Allow the cluster identity; private endpoint recommended
DNS for apps Public or private DNS for the AMS hostname is independent of API privacy
CI/CD Place runners on a network that can reach the private API, or deploy from the jump host

Smoke test after each chart

kubectl get pods -n <namespace>
kubectl get ingress -A
kubectl describe ingress <name> -n <namespace>

When Application Gateway is public, test the AMS URL from the internet even though Helm ran privately.