Vault als PKI rausgeworfen — eine Offline-CA-Hierarchie mit cert-manager

Permalink 6 min read Published:
 security  infrastructure  #cert-manager #pki #ca #tls #kubernetes #vault #trust-manager #x509 #gitops
Vault als interne Zertifizierungsstelle war bequem und ein Single Point of Failure zugleich: Läuft Vault nicht, wird kein Cert mehr ausgestellt. Ich habe die PKI auf eine klassische Offline-Hierarchie umgestellt — Root und Intermediate-Key liegen air-gapped, eine kurzlebige Sub-CA lebt als cert-manager-ClusterIssuer im Cluster, und Name Constraints erzwingen, dass kein Blatt je außerhalb meiner internen Domains signiert wird. Ein staged Cutover ohne Trust-Lücke inklusive.

Lange hat Vault in meinem Lab die internen Zertifikate ausgestellt — eine PKI-Engine, ein cert-manager-ClusterIssuer namens vault, fertig. Bequem. Und ein Single Point of Failure mit Ansage: Ist Vault sealed, abgelaufen oder beim Bootstrap, stellt niemand mehr ein Cert aus. Genau dieses Henne-Ei hat mich schon einmal in eine Break-Glass-Recovery gezwungen. Also habe ich die PKI von Vault gelöst und auf das gestellt, wofür X.509 eigentlich gedacht ist: eine Offline-Hierarchie, deren teuerste Schlüssel nie online sind.

Envoy Gateway: Ein Ingress, drei Welten und OIDC für alle

Permalink 6 min read Modified: (UPDATED)
 infrastructure  networking  #envoy-gateway #gateway-api #traefik #kubernetes #oidc #envoy #tls #httproute
Von Traefik-Ingress über die Gateway-API zu Envoy Gateway — drei Shared-Gateways für extern, intern und Tailnet, OIDC für Apps ohne SSO und Feintuning per Policy

Der Edge eines Clusters — die Stelle, an der externer Traffic auf die Workloads trifft — ist eine der Komponenten, die man besser einmal richtig baut. Bei mir hat dieser Punkt eine kleine Evolution hinter sich: von Traefik als klassischem Ingress-Controller über die Adoption der Gateway-API bis hin zu Envoy Gateway , das diese API heute exklusiv umsetzt. Dieser Beitrag ist eine ausführliche Tour durch den Aufbau.