Cryptopus ist eine praktische Applikation zum Speichern und Teilen von Passwörtern. In Kombination mit Kubernetes könnten Kubernetes Secrets verwaltet werden und damit würde ein zentraler Ort für Passwörter geschaffen. Sebastian Plattner berichtet von seiner Idee.
Cryptopus ist eine von Puzzle entwickelte OpenSource Web-Applikation zum Speichern und Teilen von Passwörtern. Passwörter (sog. Accounts) werden dabei in Gruppen zusammengefasst und diese Gruppen können an Teams freigegeben werden. Zugang zu einem Team kann wiederum über LDAP-Accounts geregelt werden. Weiter bietet Cryptopus auch seit noch nicht allzu langer Zeit eine API für den Zugriff auf Accounts an. Diese wurde bisher aber kaum verwendet. Da ich mich in meinem aktuellen Projekt mit Kubernetes und insbesondere mit Kubernetes Controller und Custom Resource Definitions beschäftige, liegt es deshalb praktisch auf der Hand, diese beiden Dinge miteinander zu kombinieren. Meine Idee ist deshalb die folgende: Kubernetes Secrets mit Hilfe von Cryptopus Accounts verwalten und somit einen zentralen Ort für Passwörter zu haben.
Die CustomeRessourceDefinition (CRD) API von Kubernetes ermöglicht es, wie der Name schon impliziert, Custom Ressourcen mit eigenem Name und Schema zu definieren. Mit einem Controller kann dann auf diese Custom Ressourcen reagiert werden. Auf die Details von Kubernetes Controller gehen ich in diesem Beitrag nicht ein. Grundlage meines Kubernetes Secret Controller für Cryptopus ist der Sample Controller von Kubernetes.
Für meinen Kubernetes Secret Controller habe ich ein CRD mit dem Namen SecretClaim erstellt. Anhand dieses SecretClaim wird ein Account in Cryptopus ausgelesen (via API) und in einem Kubernetes Secret gespeichert. Der Controller ist ausserdem auch zuständig dafür, das Secret periodisch mit Cryptopus wieder zu aktualisieren.
Ein Secret Claim sieht wie folgt aus:
apiVersion: cryptopussecretcontroller.puzzle.ch/v1alpha1 kind: SecretClaim metadata: name: mysecretclaim spec: secretName: mysecret id: [ 2256 ] refreshTime: 3600 cryptopusSecret: mynamespace/cryptopusapiconfig
- secretName definiert den Namen des zu erstellenden Kubernetes Secret; das Secret wird dabei im gleichen Namespace wie der SecretClaim erstellt
- id ist ein Array von IDs der Cryptopus Accounts, die in das Secret geladen werden sollen
- refreshTime [s] gibt an, wie oft ein Secret mit einem Cryptopus Account aktualisiert werden soll
- cryptopusSecret ist eine Referenz auf ein weiteres Secret, das alle Details zu Cryptopus wie API URL, API UserName und API Token enthält
Sobald der SecretClaim erstellt wurde, erstellt der Kubernetes Secret Controller daraus ein Kubernetes Secret, das wie folgt aussieht:
apiVersion: v1 data: password_2256: ... username_2256: .... kind: Secret metadata: name: mysecret type: Opaque
Dieses Secret kann dann wie gewohnt z.B. in einem Deployment verwendet werden.
Disclaimer: Alpha/early Beta Qualität! Der Kubernetes Secret Controller läuft bei uns zur Zeit in einer Test-Phase auf unserem internen OpenShift Cluster. Das Eine oder Andere kann bestimmt noch verbessert werden. Zudem schliesse ich nicht aus, dass es noch Breaking Changes z.B. beim Schema des CRD oder der Struktur des Secrets gibt. Bei Interesse an dem Projekt würde ich mich deshalb über Inputs und Verbesserungsvorschläge freuen.
Das Projekt ist auf unserem Puzzle Github Account zu finden. Weiter wird das dazugehörigen Docker-Image automatisch auf unseren Puzzle Docker Hub Account gepushed.
Zum Schluss noch: für einen unserer Kunden habe ich einen Kubernetes Secret Controller geschrieben, der HashiCorp Vault Secrets ausliest und in Kubernetes Secrets speichert. Bei Interesse daran freue ich mich über eine Kontaktaufnahme!
