Anpassen über Vault-Backends

Vault ermöglicht durch verschiedene Backends die Anpassung an individuelle Bedingungen. Dabei unterscheidet Vault zwischen Speicher-, Authentifikations- und Auditierungs-Backends.

Speicher-Backends verwalten die Geheimnisse, die dynamische Erzeugung von zeitlich begrenzten Zugängen und den entsprechenden Zugriff darauf. Die gewünschten Backends müssen Sie in den Tresor einbinden, bevor Sie diese nutzen können. Ein Backend ist vergleichbar mit einem virtuellen Dateisystem. Die unterstützten Funktionen lauten "read", "write" und "delete". Die Ablage von Geheimnissen erfolgt mittels Pfaden. Unter jedem Pfad lässt sich ein Geheimnis speichern. Die Zugriffskontrolle auf einzelne Pfade steuern Sie über Regelsätze, sogenannte Policies. Ein Beispiel dafür finden Sie etwas weiter unten. Der folgende Befehl zeigt zuerst die aktuell eingebundenen Speicher-Backends an:

$ vault mounts

Beim ersten Start sind die Backends "generic", "system" und "cubbyhole" bereits gemountet. Bei "generic" handelt es sich um einen Speicher für beliebige Geheimnisse. Das "system"-Backend speichert Konfigurationseinstellungen des Servers. Dazu gehören auch die bereits erwähnten Policies zur Zugriffskontrolle oder der Zustand der Versiegelung des Tresors. Im "cubbyhole"-Backend verwaltet Vault die Geheimnisse pro Benutzer-Token. Der Zugriff wird dabei also nicht über Policies, sondern ausschließlich über die Authentifikation am Server geregelt. In diesem Speicher können Sie also Geheimnisse hinterlegen, die nicht geteilt werden sollen.

Um die Verwendung des Servers kennenzulernen, speichern wir zunächst ein einfaches Passwort mit dem unter "secret/" eingebundenen generic-Backend und lesen es anschließend direkt wieder aus:

$ vault write /secret/geheimnis value="geheim"

$ vault read /secret/geheimnis

Hierbei gilt es zu beachten, dass Vault zwar den in "value" gespeicherten Wert verschlüsselt abgelegt, der dazugehörige Pfad jedoch unverschlüsselt bleibt. Sie sollten also vermeiden, schon den Pfad zur Speicherung vertrauenswürdiger Informationen zu nutzen. Eine Übersicht der verwendeten Pfade erhalten Sie einfach mit dem folgenden Befehl:

$ vault list /secret

In der angezeigten Liste finden Sie die verwendeten Pfade und Ordner auf der angefragten Ordner-Ebene "/secret". Dabei dürfen Geheimnisse und Unterordner sogar denselben Namen tragen. Analog zum "generic"-Backend können Sie auch den Zugriff auf das "cubbyhole"-Backend verwenden. Allerdings mit dem Unterschied, dass der list-Befehl tatsächlich nur die eigens genutzten Pfade anzeigt.

Zusätzlich zu den bereits eingebundenen existieren weitere Backends für unterschiedliche Zwecke. Darunter finden sich etwa Backends für den dynamischen Zugang zu SSH- oder MySQL-Servern, die vor allem in Cloud-Umgebungen ihren Nutzen offenbaren. Bevor wir diese beiden einrichten, schauen wir etwas genauer auf die Authentifikation- und Audit-Backends von Vault.

Bild 2: Ohne Berechtigung ist der Zugriff auf das Geheimnis logischerweise nicht möglich.

Authentifizierung via Token und Policies

Die Authentifikation am Server findet standardmäßig mittels eines Tokens statt. Beim Initialisieren des Servers wurde Ihr root-Token bereits in der Datei "~/.vault-token" hinterlegt. Wenn Sie diese Datei löschen oder sich mit einem anderen Benutzer authentifizieren wollen, fragt Vault mit dem folgendem Befehl nach Ihrem Token:

$ vault auth

Anschließend sehen Sie Informationen wie die Lebensdauer oder geltende Policies für das verwendete Token. Beim Anlegen erbt ein neues Token die zugeordnete Policy des Eltern-Tokens. Beim Widerruf eines Tokens werden alle erzeugten Kind-Token ebenfalls widerrufen. Die Zuordnung eines Tokens zu Policies lässt sich nachträglich nicht mehr ändern. Um ein Token ohne weitere Zugriffsmöglichkeiten zu erstellen, führen wir – angemeldet mit einem root-Token – den folgenden Befehl aus:

$ vault token-create -policy=default

Wenn Sie sich mit dem erstellten Token anmelden, haben Sie jetzt keinen Zugriff mehr auf das zuvor angelegte Geheimnis unter "/secret/geheimnis". Als Nächstes erstellen wir eine Policy, die einem Token Leserechte auf dem Pfad "/secret/geheimnis" gewährt und alle Rechte für den zugehörigen Ordner /secret/geheimnis/ zuteilt. Listing 2 zeigt eine entsprechende Policy. Die Policies sind, wie die Vault-Konfiguration auch, in HCL formatiert. Sie beschreiben für angegebene Pfade die jeweiligen Berechtigungen (capabilities). Mögliche Berechtigungen sind "create", "read", "update", "delete", "list" und "deny". Für den Zugriff auf speziell geschützte Bereiche gibt es noch "sudo".

path "/secret/*" {
      capabilities = ["deny"]
}
path "/secret/geheimnis" {
      capabilities = ["read"]
}
path "/secret/geheimnis/*" {
      capabilities = ["create", "read", "update", "delete", "list"]
}

Die Policy in der Datei "policy.hcl" fügen Sie mit dem folgenden Befehl unter dem Namen "ita" hinzu:

$ vault policy-write ita policy.hcl

Mit »token-create« erstellen Sie wie oben ein neues Token und ersetzen "default" durch die neu angelegte Policy "ita". An der Antwort vom Server fällt Ihnen sicher auf, dass dem Token nun beide Policies, "default" und "ita", zugeordnet sind. Die "default"-Policy ist automatisch dabei und verhindert den Zugriff auf alle nicht explizit erwähnten Pfade.

Bild 3: Der Ablauf eines SSH-Logins mit Vault, in unserem Beispiel mit Einmalpasswort (OTP).