Kong

Purpose

Kong is not the active Lumie ingress path today, but the repo still contains a full bootstrap configuration for it. This page is a reference document for those retained artifacts so engineers can recognize legacy edge configuration and avoid confusing it with the current Traefik-based runtime.

Source Paths

Path	Role
lumie-infra/bootstrap/kong/argocd.yaml	Argo CD application manifest for a Kong deployment that is not currently registered in the active bootstrap root
lumie-infra/bootstrap/kong/helm-values.yaml	Kong gateway and controller configuration
lumie-infra/bootstrap/kong/rbac-configmap.yaml	Extra RBAC for ConfigMap reads by the Kong Ingress Controller
lumie-infra/bootstrap/kong/manifests/cluster-plugins.yaml	Global redirect, CORS, JWT, and JWT-claim extraction plugins
lumie-infra/bootstrap/kong/manifests/jwt-auth.yaml	Vault-backed JWT credential and KongConsumer

If Enabled, What It Would Expose

The retained manifests describe a Kong deployment with:

• gateway enabled as a DaemonSet with hostNetwork: true;
• direct binding to ports 80 and 443;
• a controller using the kong/kubernetes-ingress-controller image;
• cluster-wide plugins for HTTPS redirect, CORS, JWT validation, and header injection;
• Vault-sourced JWT credentials in the kong namespace.

The most security-sensitive part of the config is the gateway container security context:

gateway:
  deployment:
    daemonset: true
    hostNetwork: true
  containerSecurityContext:
    runAsNonRoot: false
    runAsUser: 0
    allowPrivilegeEscalation: true

That is materially different from the current Traefik path and from most Lumie workload security defaults.

Legacy Runtime Model

Contract Drift

Kong is the clearest cluster-networking drift in this slice:

Inspected source	Current reality
lumie-infra/README.md says ingress is Kong	lumie-infra/AGENTS.md says the active ingress is Traefik and there is no API gateway in front of it
bootstrap/kong/argocd.yaml exists	bootstrap/kustomization.yaml does not register it
Kong plugins and consumer manifests exist	The live cluster inspected on June 14, 2026 had no argocd Application named kong and no kong namespace
Repo contains Traefik-based app ingresses	rg found no active ingressClassName: kong usage in app manifests

In other words, Kong is currently repo-only legacy configuration.

Operational Guidance

• Do not treat bootstrap/kong/ as the current edge path when debugging production ingress.
• If Kong were reactivated, it would need more than an app sync: the bootstrap root would have to register it, application ingress classes would need review, and the security posture would change because the gateway binds host ports as root.
• JWT and header-extraction behavior described in the Kong plugins is not active in the current cluster. Current auth remains application-level behind Traefik.

Failure Modes

Failure point	Impact
Legacy docs or comments treated as current	Engineers troubleshoot or design against the wrong ingress stack
Kong re-enabled without ingress-class migration	Traffic can bifurcate between Traefik and Kong in hard-to-debug ways
Host-network/root assumptions ignored	Security exceptions can reappear unexpectedly in bootstrap reviews

Verification

Repo checks:

rg -n "kong|KongClusterPlugin|KongConsumer|ingress.class: kong|ingressClassName: kong" \
  lumie-infra/bootstrap/kong lumie-infra

Live-cluster checks that currently demonstrate absence:

kubectl get app -n argocd kong
kubectl get ns kong