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 https://nexus.sphereon.com/repository/edk-helm. The Enterprise Development Kit Deployment repository provides example values files and scripts.

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.

Prerequisites​

Before installing, create the target namespace and all credentials described in Images and Helm chart:

  • registry pull credentials;
  • separate platform and tenant database credential Secrets;
  • a runtime Secret containing independently generated internal-client-secret and keystore-password values;
  • a wildcard TLS Secret, unless cert-manager will create it;
  • a pinned enterprise image tag from your OEM, MSP, or EDK distribution channel.

The chart does not deploy PostgreSQL or generate these credentials. The runtime Secret name must be configured through serviceIdentity.internalClientExistingSecret and keystore.existingSecret.

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 deployment repository 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 a database overlay, the Cilium gateway overlay, and your environment-specific domain and image settings. The example below uses the in-cluster Postgres overlay; use the managed Postgres overlay when applicable:

helm repo add edk-helm https://nexus.sphereon.com/repository/edk-helm --username <username> --password <token>

helm upgrade --install edk-enterprise edk-helm/edk-enterprise \
  --namespace edk \
  -f helm/edk-enterprise/examples/shared-postgres-values.yaml \
  -f helm/edk-enterprise/examples/gateway-cilium-values.yaml \
  --set global.imageTag=<enterprise-version> \
  --set 'global.imagePullSecrets[0]=edk-registry-credentials' \
  --set global.platformBaseDomain=example.com \
  --set gateway.baseDomain=example.com \
  --set platform.externalBaseUrl=https://platform.example.com \
  --set platform.bootstrap.issuer=https://platform.example.com \
  --set serviceIdentity.internalClientExistingSecret=edk-runtime-secrets \
  --set keystore.existingSecret=edk-runtime-secrets

Render with the same values before installing. Missing runtime Secret references are Helm errors. A configured name whose Secret object or keys do not exist is a Kubernetes startup error; inspect pod events for secret ... not found or couldn't find key ... without printing Secret data.

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​