Externe Zugriffe einrichten

Die Verwaltung vieler Tokens führt schnell zu viel Dokumentation beim Administrator. Vault bietet daher zusätzlich zu den Tokens weitere Möglichkeiten zur Authentifikation von Benutzern. Neben TLS-Zertifikaten, LDAP und weiteren Backends lässt sich auch GitHub verwenden, um den Aufwand bei der Pflege zu minimieren. Dafür binden Sie zunächst das Authentifizierungs-Backend ein. Anschließend konfigurieren Sie die Organisation für das Backend, in diesem Fall "IT-Administrator":

$ vault auth-enable github

$ vault write auth/github/config organization=IT-Administrator

Für den erfolgreichen Zugriff müssen Sie allerdings noch eine Policy konfigurieren, die Vault den Benutzern nach dem Login zuordnet. Dies lässt sich über GitHub-Teams innerhalb der Organisation bewerkstelligen. Alle Mitglieder aus dem Administratoren-Team erhalten mit folgendem Befehl root-Zugriff auf dem Server:

$ vault write auth/github/map/teams/administratoren value=root

Die Anmeldung mit einem GitHub-Benutzer, der Mitglied der Unternehmens-Gruppe bei GitHub ist, funktioniert nun mit dem bei GitHub hinterlegten Personal Access Token:

$ vault auth -method=github token=GitHub Personal Access Token

Bild 4: Der SSH-Login erfolgt mit dem generierten Einmalpasswort.

SSH-Login auf Cloud-Umgebung

Insbesondere in heutigen dynamischen Cloud-Umgebungen benötigen Administratoren einen Überblick Ihrer Logins auf verschiedenen Maschinen. Das ist vor allem dann schwierig, wenn das Admin-Team regelmäßigen Änderungen unterliegt. Praktisch, wenn Sie sich gar nicht mehr darum kümmern müssen, SSH-Public-Keys zu pflegen oder gemeinsame Passworte zur Administration zu verteilen und zu aktualisieren. Am Beispiel einer Amazon-Elastic-Cloud-(EC2)-Instanz konfigurieren wir Vault für den SSH-Login. EC2 erzeugt Instanzen aus einer Vorlage, dem Amazon Machine Image (AMI). Wenn diese Vorlage bereits Vaults SSH-Backend [3] enthält, wird die spontane Nutzung zum Kinderspiel.

Die Einrichtung unter CentOS etwa gelingt recht unkompliziert. Die Überprüfung der Login-Daten übernimmt ein spezielles PAM-Modul, das mit dem Vault-Server kommuniziert und das Einmalpasswort überprüft. Für den Fall, dass die Kommunikation mit dem Vault-Server beim Test einmal nicht zustandekommt, sollten Sie einen Public-Key als Backup auf der Maschine installieren. Für die Nutzung fügen Sie zunächst das SSH-Backend zu Ihrem Tresor hinzu:

$ vault mount ssh

Das PAM-Modul "vault-ssh-helper" beziehen Sie aus dem Git-Repository [3]. Nach der Installation auf dem Zielserver müssen Sie die PAM-Konfiguration für den SSH-Daemon sowie die sshd_config überprüfen, damit SSH tatsächlich PAM für Logins verwendet. Folgen Sie dabei der Dokumentation auf GitHub [3] und überprüfen Sie die Konfiguration mit folgendem Kommando:

$ vault-ssh-helper -verify-only -config=/etc/vault-ssh-helper.d/config.hcl

Bevor der Login funktioniert, müssen Sie den Zugang noch im Tresor konfigurieren. Dies gelingt mit dem fol­genden Befehl, dabei setzen Sie den Typ des Schlüssels auf "otp" und den Standardbenutzer auf den üblichen "ec2-user". Den Rollennamen "ec2instance" können Sie beliebig anpassen. Die Nutzung des Schlüssels ist beschränkt auf die in "cidr_list" gelisteten Maschinen (beziehungsweise das entsprechende Subnetz).

$ vault write ssh/roles/ec2instance key_type=otp default_user=es2-user \

> cidr_list=w.x.y.z/32

Ob der Server einen Einmalschlüssel generiert, testen Sie mit dem nächsten Befehl. Dabei ist zu beachten, dass das SSH-Backend diesen generiert und dann in den geschützten Speicher schreibt. Daher beginnt das Kommando mit "vault write". Schreiben Sie nun die Credentials für den zuvor gewählten Rollennamen:

$ vault write ssh/creds/ec2instance ip=w.x.y.z

Trotz erfolgreichen Tests auf beiden Seiten kann es passieren, dass ein Login nicht möglich ist, wenn SELinux aktiviert und enforced ist. Dann müssen Sie eventuell die Berechtigungen zum Zugriff auf das Netzwerk für den SSH-Login-Prozess anpassen. Versuchen Sie den Login aber zunächst von Ihrem Client-Rechner mit dem Befehl:

$ vault ssh -role ec2instance ec2-user@w.x.y.z

Das Einmalpasswort steht nun in der ersten Zeile der Ausgabe. Überprüfen Sie den SSH-Fingerabdruck und geben das Passwort ein. Zur weiteren Automatisierung können Sie das Programm "sshpass" installieren. Allerdings funktioniert dann die manuelle Überprüfung des SSH-Fingerabdrucks nicht mehr. Klappt der Login nicht, prüfen Sie auf dem Server die Logdaten in der Datei "/var/log/audit/audit.log" auf einen ähnlichen Eintrag:

[Error]: Put https://vault.example.com:8200/v1/ssh/verify: dial tcp w.x.y.z:8200; connect: permission denied

Wenn dieser existiert, können Sie direkt mit Hilfe der Einträge die SELinux-Konfiguration anpassen:

$ grep 'avc' /var/log/audit/audit.log | audit2allow -R -M vault.allow

$ semodule -i vault.allow.pp

Nun sollte der Login erfolgreich sein. Erstellen Sie jetzt eine Policy für den Zugriff auf die unterschiedlichen SSH-Logins. Natürlich können Sie den SSH-Login auch auf Servern nutzen, die Sie nicht in einem Cloud-Umfeld einsetzen. Somit werden Mitarbeiterwechsel durch Widerruf des Tokens oder Aktualisieren des GitHub-Teams zu einem Kinderspiel. Die Auditierung von Vault ermöglicht darüber hinaus die Nachvollziehbarkeit von Benutzeranmeldungen bei geteilten SSH-Benutzerkonten.