Skip to main content
Version: v0.25.0 (Latest)

Install on Kubernetes (Cilium)

This guide deploys the EDK enterprise stack on Kubernetes using the Cilium Gateway API as the single-port front door, with the published nexus.sphereon.com/edk-docker/enterprise-* images and the edk-enterprise Helm chart from the Enterprise Development Kit Deployment repository. Customer deployments install helm/edk-enterprise.

One Gateway with a wildcard HTTPS listener terminates TLS for the operator host and all tenant hosts, and HTTPRoutes fan out by host and path. The result satisfies the gateway contract: Cilium Gateway preserves the inbound Host header by default, so tenant resolution works without extra tuning.

The edk-enterprise Helm Gateway Values​

The edk-enterprise Helm chart renders the Gateway and the per-service HTTPRoutes from a gateway.* values block. The chart ships an example values file at helm/edk-enterprise/examples/gateway-cilium-values.yaml:

gateway:
  enabled: true
  className: cilium
  operatorHost: platform
  baseDomain: example.com
  tls:
    mode: secret
    secretName: edk-wildcard-tls
  httpRedirect: true

ingress:
  legacy:
    enabled: false

The fields map directly to the host scheme and contract:

  • enabled: true turns on the Gateway and HTTPRoutes.
  • className: cilium selects the Cilium GatewayClass.
  • operatorHost: platform and baseDomain: example.com produce the operator host platform.example.com and the tenant wildcard *.example.com.
  • tls.mode and the cert fields configure wildcard TLS, covered below.
  • httpRedirect: true adds an HTTP listener on 80 that redirects to HTTPS.

The rendered Gateway has a single HTTPS listener on port 443 with hostname *.example.com, tls.mode: Terminate, and a certificate reference. That one wildcard listener serves both the operator host and every tenant host.

Wildcard TLS​

The listener needs TLS material valid for the operator host and every tenant host. A wildcard certificate for *.example.com covers first-level subdomains, including platform.example.com and tenant hosts such as acme.example.com. You may still list platform.example.com explicitly as a SAN when your CA, gateway, or audit policy expects it. Individual certificates per tenant host also work, but tenant onboarding must provision the certificate before that tenant host is made public.

TLS Secret​

Set tls.mode: secret and reference a pre-created Kubernetes TLS secret holding the wildcard certificate and key:

gateway:
  tls:
    mode: secret
    secretName: edk-wildcard-tls

Create the secret from a certificate you already hold, for example one issued by your corporate CA or an external ACME flow.

cert-manager with DNS-01​

To issue and renew the wildcard automatically, use cert-manager with a DNS-01 solver. A wildcard SAN cannot be validated with HTTP-01, so DNS-01 is required. Set tls.mode: certManager and the cluster issuer; the chart then annotates the Gateway with cert-manager.io/cluster-issuer so cert-manager provisions the wildcard certificate into the referenced secret:

gateway:
  tls:
    mode: certManager
    clusterIssuer: letsencrypt-dns01
    secretName: edk-wildcard-tls

Configure the cluster issuer with a DNS provider that can answer the _acme-challenge records for your base domain.

Disabling the Legacy Ingress​

ingress.legacy.enabled: false turns off the classic per-service Ingress objects so the Gateway is the only public entry point. Leave the legacy ingress disabled on Cilium; it exists for cloud load balancer paths that route through classic Ingress, covered in Cloud load balancers.

Install the Chart​

Install or upgrade the chart with the Cilium example values plus your own base domain and image settings:

helm upgrade --install edk-enterprise helm/edk-enterprise \
  -f helm/edk-enterprise/examples/gateway-cilium-values.yaml \
  --set gateway.baseDomain=example.com

After the release is ready, point your wildcard DNS record *.example.com and the operator host at the Gateway's external address. The operator host then resolves at https://platform.example.com and each tenant at https://<tenant>.example.com.

Relationship to the East-West Network Policy​

The Gateway handles north-south public traffic. Internal service-to-service traffic, including KMS command routing over gRPC 9090, stays east-west and is governed by a separate CiliumNetworkPolicy. The gRPC port is never placed on the public Gateway. Keep the east-west policy in place so the tenant runtime services can reach tenant KMS and the platform configuration service while the public surface stays limited to the single HTTPS listener. The Roles and Topology page describes which services talk to which.

Next Steps​