Mattermost auf Kubernetes: Operator, Datenbank und SSO

Auf Kubernetes betreibe ich Mattermost nicht von Hand, sondern über einen Operator. Der erzeugt die eigentliche Anwendung aus einer knappen Beschreibung und hält sie am Leben. Der Weg dahin hat drei Bausteine: die Anwendung selbst als Operator-Ressource, eine Datenbank von außen und die Anbindung an einen zentralen Identity-Provider für das Login. Diese drei gehe ich der Reihe nach durch.

Schritt 1: Der Operator und die Mattermost-Ressource

Statt Deployments, Services und Ingress einzeln zu pflegen, installiere ich den Mattermost-Operator und beschreibe die Anwendung als eine einzige Ressource. Der Operator leitet daraus alles Nötige ab:

apiVersion: installation.mattermost.com/v1beta1
kind: Mattermost
spec:
  version: 11.8.1
  image: mattermost/mattermost-enterprise-edition
  replicas: 1
  ingress:
    host: chat.example.de
  database:
    external:
      secret: mattermost-db-connection

Änderungen laufen über diese Ressource. Wer die Version im Feld version hochsetzt, bekommt vom Operator einen kontrollierten Rollout, kein Hantieren am laufenden Deployment.

Schritt 2: Die Datenbank kommt von außen

Mattermost braucht eine Postgres-Datenbank. Die betreibe ich nicht im selben Pod, sondern separat, und reiche die Zugangsdaten als Secret herein (oben mattermost-db-connection, referenziert unter database.external.secret). Im Cluster erzeugt dafür ein Datenbank-Operator die Postgres-Instanz. Wie das mit dem Zalando-Operator aussieht und welche Falle beim Aufräumen lauert, habe ich im Beitrag Zalando-Postgres-Operator: adoptieren und die PVC-Falle beschrieben.

Schritt 3: Login über Keycloak

Interessant wird es beim Zugang. Statt einer eigenen Nutzerverwaltung binde ich Mattermost an einen zentralen Identity-Provider an, hier Keycloak, über OpenID Connect. Ein Identity-Provider ist der eine Dienst, bei dem sich Nutzer anmelden und der anderen Anwendungen bestätigt, wer sie sind. Dann erscheint auf der Anmeldeseite neben Benutzername und Passwort der Knopf für die Anmeldung per SSO:

Die Tücke dabei ist der Aussteller (Issuer): Keycloak muss unter genau dem Hostnamen erreichbar sein, den es in seine Tokens schreibt, sonst schlägt die Prüfung fehl. Interner Service-Name für den Server-zu-Server-Weg, öffentlicher Hostname für den Browser, beides muss zusammenpassen.

Betrieb: ehrlich mehr bewegliche Teile

Der Operator-Weg ist sauber, aber er bringt bewegliche Teile mit: den Operator selbst, die Datenbank samt ihrem Operator, das Zertifikat, die OIDC-Anbindung. Für ein großes Team, das ohnehin auf Kubernetes fährt, ist das genau richtig. Für eine Handvoll Leute ist eine schlankere Installation oft die vernünftigere Wahl.

Sie wollen Team-Kommunikation self-hosted, mit einem zentralen Login? Ich betreibe Chat, Identity und die Datenbank als zusammenhängendes, dokumentiertes System. Mehr unter Sichere Kommunikation, das Erstgespräch ist unverbindlich.