Philipp Kürsten hat vor Kurzem in seinem Beitrag hier im Blog gezeigt, wie man MinIO auf Kubernetes durch SeaweedFS ersetzt und den Umzug per Helm-Chart und rclone-Job abwickelt. Die Anwendung sprach am Ende weiterhin S3 – nur mit einem anderen Endpoint dahinter. S3 ist aber nicht der einzige Zugriffsweg, den SeaweedFS über den Filer anbietet. Für Szenarien, in denen Zulieferer oder Batch-Jobs klassisch per Dateiübertragung andocken sollen, bringt SeaweedFS seit Kurzem einen eigenen SFTP-Server mit – inklusive zertifikatsbasierter Authentifizierung ganz ohne Passwörter oder verteilte Public Keys.
Diese Funktion stammt aus einem eigenen Beitrag zum SeaweedFS-Projekt (seaweedfs/seaweedfs#9815), der mittlerweile veröffentlicht wurde. Im Rahmen meines k3d-Showcase-Repos habe ich daraus einen vollständigen Demo-Aufbau gebaut: das offizielle Helm-Chart im All-in-One-Modus (S3 und SFTP in einem Pod), eine lokale SSH-CA und ein Setup-Skript, das den kompletten Zertifikatsfluss automatisiert.
Warum SeaweedFS auf Zertifikate statt Public Keys setzt
Der klassische SFTP-Zugang über hinterlegte Public Keys funktioniert, skaliert aber schlecht: Jeder neue Client braucht einen Eintrag auf der Serverseite, und ein Schlüsselwechsel bedeutet Rollout auf allen Servern. Bei zertifikatsbasierter SSH-Auth dreht sich das um. Eine lokale Certificate Authority signiert kurzlebige Nutzerzertifikate, der Server kennt nur den öffentlichen Schlüssel dieser CA. Ein Client ist damit automatisch vertrauenswürdig, solange sein Zertifikat gültig ist – ganz ohne dass der Server ihn vorher kennengelernt hat. Widerruf bedeutet in der Praxis schlicht: Das Zertifikat wird nicht erneut signiert.
SeaweedFS bildet dafür drei Schlüsselrollen ab:
- Server-Hostkey – identifiziert den SFTP-Server gegenüber dem Client, wie bei jedem SSH-Server.
- User-CA-Key – signiert Nutzerzertifikate; sein öffentlicher Teil landet beim Server.
- Nutzerzertifikat – vom Client verwendet, von der CA signiert, mit Gültigkeitsfenster.
Der Server bekommt den öffentlichen CA-Schlüssel über die neue Option -sftp.trustedUserCAKeysFile im OpenSSH-authorized_keys-Format übergeben. Alles, was mit dieser CA signiert ist, wird akzeptiert – alles andere nicht.
All-in-One statt getrennter StatefulSets auf Kubernetes
Für den produktiven HA-Aufbau, den Philipp beschrieben hat, ergeben getrennte StatefulSets pro Rolle Sinn. Für den Showcase reicht der All-in-One-Modus des Helm-Charts, bei dem Master, Volume, Filer, S3-Gateway und SFTP-Server in einem Pod auf demselben Kubernetes-Cluster laufen:
# values.yaml (Ausschnitt)
global:
enableSecurity: false
sftp:
enabled: true
port: 2022
sshPrivateKeyPath: /etc/sftp/keys/ssh_host_ed25519_key
trustedUserCAKeysFile: /etc/sftp/keys/user_ca.pub
s3:
enabled: true
# bestehende statische Identität für Velero bleibt unangetastet
Die S3-Seite bleibt dabei unverändert bestehen, inklusive der statischen seaweedadmin-Identität und eines zusätzlichen seaweedfs-s3-Alias-Service. Der Grund: Ein bestehender Velero-Showcase im selben Repo verlässt sich auf genau diesen Endpoint, und der sollte durch den SFTP-Umbau nicht brechen.
Der Signier-Ablauf im SeaweedFS-Showcase
setup.sh übernimmt die komplette Schlüsselerzeugung vor dem Helm-Install:
# CA erzeugen (einmalig)
ssh-keygen -t ed25519 -f user_ca -N "" -C "seaweedfs-demo-ca"
# Server-Hostkey erzeugen
ssh-keygen -t ed25519 -f ssh_host_ed25519_key -N "" -C "seaweedfs-sftp-host"
# Nutzerschlüssel erzeugen und mit der CA signieren
ssh-keygen -t ed25519 -f client_key -N "" -C "demo-user"
ssh-keygen -s user_ca -I demo-user -n demo-user -V +1h client_key.pub
Die beiden erzeugten Public-Key-Dateien (Hostkey und CA) werden als Kubernetes-Secrets bereitgestellt und über die Helm-Values eingebunden; der signierte Nutzerschlüssel bleibt lokal beim Client. Anschließend rollt setup.sh den Chart aus und legt einen Demo-Bucket an.
connect.sh richtet anschließend ein Port-Forwarding auf den SFTP-Port ein und fährt einen vollständigen Roundtrip: Upload, Listing, Download – alles über das signierte Zertifikat, ohne dass irgendwo ein Passwort oder ein einzeln hinterlegter Public Key vorkommt.
Der Negativtest im SeaweedFS-SFTP-Server
Ein Setup ist erst dann glaubwürdig, wenn auch der Fehlerfall stimmt. Der Showcase prüft deshalb explizit, dass ein unsignierter Schlüssel abgelehnt wird:
sftp -i unsigned_key -P 2022 demo-user@localhost
# Permission denied (publickey)
Nur Zertifikate, die tatsächlich von der hinterlegten CA signiert wurden, kommen durch – ein selbst erzeugter, aber nicht signierter Schlüssel schlägt fehl. Das ist genau das Verhalten, das den Ansatz von hinterlegten Public Keys unterscheidet: Vertrauen hängt an der CA, nicht an einzelnen Einträgen.
Was das für bestehende SeaweedFS-Setups bedeutet
Wer wie im vorherigen Beitrag beschrieben gerade von MinIO auf ein SeaweedFS-Setup in Kubernetes migriert, bekommt SFTP quasi geschenkt dazu – der Filer, der ohnehin für S3 mitläuft, bedient jetzt zusätzlich klassische SFTP-Clients. Für Alt-Systeme oder Partner, die nur SFTP sprechen, entfällt damit ein separates SFTP-Gateway vor dem Object Store. Die Zertifikatsauthentifizierung ist dabei kein reines SeaweedFS-Feature, sondern folgt dem etablierten OpenSSH-CA-Mechanismus – wer den schon aus klassischen Bastion-Host-Setups kennt, findet hier ein vertrautes Muster wieder, nur eben direkt im Filer integriert.
Für den produktiven Einsatz gilt dasselbe wie beim S3-Gateway aus Philipps Beitrag: Erst im Staging testen, insbesondere die Interaktion zwischen SFTP- und S3-Zugriff auf denselben Bucket, und die Gültigkeitsdauer der Nutzerzertifikate bewusst kurz halten, um das Widerrufsproblem klassischer Public-Key-Verfahren gar nicht erst zu bekommen.
Der vollständige Showcase inklusive setup.sh, connect.sh und der Dokumentation liegt im k3d-bootstrap-cluster-Repository unter examples/seaweedfs/.
