#tls

tailnet-operator: Verbindungen deklarieren statt Proxys verkabeln

Permalink 12 min read Published:
 infrastructure  networking  #tailnet-operator #headscale #tailscale #kubernetes #operator #gitops #networking #tls #golang
Kubernetes und Headscale sprechen nicht automatisch dieselbe Sprache. Mein tailnet-operator verbindet beide Welten: Services für entfernte Ziele, private HTTPS-Eingänge, abgeleitete Zugriffsregeln und Statusmeldungen, die mehr sagen als ‚Pod läuft‘. Eine Vorstellung anhand des realen Lab-Einsatzes.

Vom Laptop ist die Datenbank erreichbar, aus dem Pod bleibt die Verbindung hängen. Dabei steht der Tunnel, die Route ist angekündigt und der Proxy läuft. Die Ursache kann im Zusammenspiel von Kubernetes-Service, Headscale-Policy, Routenfreigabe und DNS liegen. Keines dieser Systeme prüft jedoch allein, ob alle Voraussetzungen für die Verbindung erfüllt sind.

Für diese Lücke entwickle ich tailnet-operator. Er bildet Verbindungen zwischen Kubernetes und einem Headscale-Tailnet als eigene Ressourcen ab. Damit bekommt ein Namespace einen stabilen Service für ein entferntes Ziel oder eine Anwendung einen privaten HTTPS-Eingang. Die zugehörigen Identitäten, Freigaben und Statusinformationen entstehen aus derselben Deklaration.

Der Operator nutzt die vorhandene VPN-Infrastruktur und übernimmt die Betriebslogik, die bisher zwischen Kubernetes und Headscale von Hand gepflegt werden musste.

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.