fix(homarr): add AUTH_OIDC_URI + email account linking — homarr hides the Authentik sign-in button unless AUTH_OIDC_URI (authorize endpoint) is set alongside AUTH_OIDC_ISSUER (per authentik/homarr SSO docs); was the missing var

2026-08-18 15:08:04 -07:00
parent fc10a9871a
commit c3ffc611f4
7 changed files with 224 additions and 0 deletions
@@ -0,0 +1,43 @@
+# Edge route for the API gateway.
+#
+# Lives here rather than in the central k8s/bootstrap/ingress/ingress.yaml
+# because that Application syncs in wave 1, before namespace `api` exists.
+#
+# nginx terminates TLS with the wildcard *.riotpiao.com cert (served as its
+# default-ssl-certificate, so no per-rule `tls:` block is needed) and forwards
+# plain HTTP to kong-proxy. Kong then does the real routing, from Ingresses
+# carrying `ingressClassName: kong`.
+#
+# Catch-all `/` on purpose: everything under this host belongs to Kong. Listing
+# per-API paths here would duplicate Kong's routing table inside nginx, and the
+# two copies would drift.
+#
+# In-cluster callers should prefer http://kong-proxy.api.svc.cluster.local
+# directly. Resolving api.riotpiao.com sends them out to nginx and back in,
+# which is a pointless hairpin unless they need TLS or the public hostname.
+apiVersion: networking.k8s.io/v1
+kind: Ingress
+metadata:
+  name: api
+  namespace: api
+  annotations:
+    # An API gateway carries streaming responses (SSE, gRPC-web, LLM token
+    # streams). nginx's 60s default read timeout and its response buffering
+    # would truncate or stall those.
+    nginx.ingress.kubernetes.io/proxy-read-timeout: "3600"
+    nginx.ingress.kubernetes.io/proxy-send-timeout: "3600"
+    nginx.ingress.kubernetes.io/proxy-buffering: "off"
+    nginx.ingress.kubernetes.io/proxy-body-size: "0"
+spec:
+  ingressClassName: nginx
+  rules:
+    - host: api.riotpiao.com
+      http:
+        paths:
+          - path: /
+            pathType: Prefix
+            backend:
+              service:
+                name: kong-proxy
+                port:
+                  number: 80
@@ -0,0 +1,97 @@
+# Kong Gateway — cluster-internal API gateway (namespace `api`).
+#
+# Chart: kong/kong 3.4.1 (appVersion 3.9). Only overrides are listed; every key
+# here was checked against `helm show values kong/kong --version 3.4.1`, because
+# Helm silently ignores unknown keys — a typo is a no-op, not an error.
+#
+# ── Topology ────────────────────────────────────────────────────────────────
+#   external:  client -> nginx (TLS, wildcard *.riotpiao.com) -> kong-proxy:80
+#   internal:  pod    -> kong-proxy.api.svc.cluster.local:80
+#
+# nginx stays the single edge and the only LoadBalancer (192.168.1.160). Kong is
+# the policy/routing layer behind it, so it needs no LB IP and no TLS of its own
+# — hence ClusterIP and proxy.tls disabled. Giving Kong its own IP from
+# homelab-pool would mean duplicating cert-manager wiring and diverging from the
+# CoreDNS convention that sends every *.riotpiao.com host to nginx.
+#
+# ── Routing model ───────────────────────────────────────────────────────────
+# Consumers publish an Ingress with `ingressClassName: kong`; the controller
+# turns it into a Kong route. `nginx` remains the default IngressClass, so this
+# is strictly opt-in and no existing Ingress changes behaviour.
+
+# Without this the release name is prefixed onto everything (`kong-kong-proxy`).
+# Pinning it keeps the Service name stable and independent of the release name,
+# which matters because the nginx Ingress in k8s/bootstrap/ingress/ingress.yaml
+# references it by name.
+fullnameOverride: kong
+
+# Two replicas so a node drain or rollout doesn't take the gateway down. Kong is
+# stateless in DB-less mode, so replicas are pure redundancy.
+replicaCount: 2
+
+env:
+  # DB-less. Config comes from Kubernetes objects via the ingress controller, so
+  # git stays the source of truth. A Postgres-backed Kong would put live routing
+  # config in a database mutated through the Admin API — state outside git, plus
+  # migration Jobs on every upgrade.
+  database: "off"
+
+ingressController:
+  enabled: true
+  ingressClass: kong
+  # The chart's ingress-class template is gated on
+  # `.Capabilities.APIVersions.Has "networking.k8s.io/v1/IngressClass"`, so a
+  # bare `helm template` renders nothing. ArgoCD passes --api-versions from the
+  # live cluster, so it does render there — verify `kubectl get ingressclass
+  # kong` after the first sync rather than assuming it.
+  createIngressClass: true
+  # Deliberately empty: setting is-default-class here would hijack every Ingress
+  # in the cluster that omits ingressClassName. nginx keeps that role.
+  ingressClassAnnotations: {}
+
+proxy:
+  enabled: true
+  # Chart default is LoadBalancer, which would claim an IP from homelab-pool.
+  type: ClusterIP
+  http:
+    enabled: true
+    servicePort: 80
+    containerPort: 8000
+  # nginx already terminated TLS; a second handshake to the same cluster buys
+  # nothing and would need Kong to hold its own certificate.
+  tls:
+    enabled: false
+
+# No Service for the Admin API. The controller reaches it over localhost inside
+# the pod, so exposing it would only create an unauthenticated write path to the
+# gateway's entire configuration.
+admin:
+  enabled: false
+
+# Kong Manager UI — chart default is `enabled: true` with type NodePort, which
+# would open a port on every node. Not wanted.
+manager:
+  enabled: false
+
+resources:
+  requests:
+    cpu: 200m
+    memory: 256Mi
+  limits:
+    cpu: "2"
+    memory: 1Gi
+
+podDisruptionBudget:
+  enabled: true
+  minAvailable: 1
+
+# Spread the two replicas across nodes; `ScheduleAnyway` so a single-node
+# situation degrades to co-location instead of leaving a pod Pending.
+topologySpreadConstraints:
+  - maxSkew: 1
+    topologyKey: kubernetes.io/hostname
+    whenUnsatisfiable: ScheduleAnyway
+    labelSelector:
+      matchLabels:
+        app.kubernetes.io/name: kong
+        app.kubernetes.io/instance: kong
@@ -0,0 +1,11 @@
+apiVersion: kustomize.config.k8s.io/v1beta1
+kind: Kustomization
+# Explicit allowlist so kong-values.yaml in this directory is NOT treated as a
+# manifest — it is Helm input consumed by the chart source of the `kong`
+# Application, not a Kubernetes object. Anything new added here must be listed
+# or it is silently dropped with no error and no drift shown.
+resources:
+  - ingress.yaml
+# No top-level `namespace:` transformer on purpose: ingress.yaml sets its own
+# namespace, and the transformer rewrites metadata.namespace on every resource
+# it builds, which is a trap for anything cross-namespace added later.