Dieses Lab wurde mit unserem Partner HashiCorp entwickelt. Ihre personenbezogenen Daten werden möglicherweise an HashiCorp, den Lab-Sponsor, weitergegeben, wenn Sie in Ihrem Kontoprofil zugestimmt haben, dass Ihnen Produktupdates, Mitteilungen und Angebote zugesandt werden.

GSP1004

Übersicht

Vault verwendet Richtlinien, um das Verhalten von Clients zu steuern und die rollenbasierte Zugriffssteuerung (Role-Based Access Control, RBAC) durch Angabe von Zugriffsrechten (Autorisierung) zu implementieren. Mit Richtlinien lässt sich deklarativ festlegen, welche Zugriffe auf bestimmte Pfade und Vorgänge erlaubt oder untersagt sind. In diesem praxisorientierten Lab erfahren Sie, wie Sie Vault-Richtlinien erstellen und anwenden.

Ziele

Aufgaben in diesem Lab:

• Vault-Richtlinien erstellen
• Vault-Richtlinien verwalten
• Vault-Richtlinien verknüpfen
• Vault-Richtlinien prüfen und testen

Einrichtung und Anforderungen

Vor dem Klick auf „Start Lab“ (Lab starten)

Lesen Sie diese Anleitung. Labs sind zeitlich begrenzt und können nicht pausiert werden. Der Timer beginnt zu laufen, wenn Sie auf Lab starten klicken, und zeigt Ihnen, wie lange Google Cloud-Ressourcen für das Lab verfügbar sind.

In diesem praxisorientierten Lab können Sie die Lab-Aktivitäten in einer echten Cloud-Umgebung durchführen – nicht in einer Simulations- oder Demo-Umgebung. Dazu erhalten Sie neue, temporäre Anmeldedaten, mit denen Sie für die Dauer des Labs auf Google Cloud zugreifen können.

Für dieses Lab benötigen Sie Folgendes:

• Einen Standardbrowser (empfohlen wird Chrome)

Hinweis: Nutzen Sie den privaten oder Inkognitomodus (empfohlen), um dieses Lab durchzuführen. So wird verhindert, dass es zu Konflikten zwischen Ihrem persönlichen Konto und dem Teilnehmerkonto kommt und zusätzliche Gebühren für Ihr persönliches Konto erhoben werden.

• Zeit für die Durchführung des Labs – denken Sie daran, dass Sie ein begonnenes Lab nicht unterbrechen können.

Hinweis: Verwenden Sie für dieses Lab nur das Teilnehmerkonto. Wenn Sie ein anderes Google Cloud-Konto verwenden, fallen dafür möglicherweise Kosten an.

Lab starten und bei der Google Cloud Console anmelden

1. Klicken Sie auf Lab starten. Wenn Sie für das Lab bezahlen müssen, wird ein Dialogfeld geöffnet, in dem Sie Ihre Zahlungsmethode auswählen können. Auf der rechten Seite befindet sich der Bereich Lab-Einrichtung und ‑Zugriff:

   • Button Google Cloud Console öffnen
   • Die temporären Anmeldedaten (Nutzername und Passwort), die Sie für dieses Lab verwenden müssen
   • Gegebenenfalls weitere Informationen für dieses Lab

   Der Lab-Timer befindet sich oben auf der Seite und zeigt die verbleibende Zeit an.

2. Klicken Sie auf Google Cloud Console öffnen. Wenn Sie Chrome verwenden, können Sie auch rechtsklicken und Link in Inkognitofenster öffnen auswählen.

   Im Lab werden Ressourcen aktiviert. Anschließend wird ein weiterer Tab mit der Seite „Anmelden“ geöffnet.

   Tipp: Ordnen Sie die Tabs nebeneinander in separaten Fenstern an.

   Hinweis: Wird das Dialogfeld Konto auswählen angezeigt, klicken Sie auf Anderes Konto verwenden.

3. Kopieren Sie bei Bedarf den folgenden Nutzernamen und fügen Sie ihn in das Dialogfeld Anmelden ein.

   {{{user_0.username | "Username"}}}

   Sie finden den Nutzernamen auch im Bereich Lab-Einrichtung und ‑Zugriff.

4. Klicken Sie auf Weiter.

5. Kopieren Sie das folgende Passwort und fügen Sie es in das Dialogfeld Willkommen ein.

   {{{user_0.password | "Password"}}}

   Sie finden das Passwort auch im Bereich Lab-Einrichtung und ‑Zugriff.

6. Klicken Sie auf Weiter.

   Wichtig: Sie müssen die für das Lab bereitgestellten Anmeldedaten verwenden. Nutzen Sie nicht die Anmeldedaten Ihres Google Cloud-Kontos. Hinweis: Wenn Sie Ihr eigenes Google Cloud-Konto für dieses Lab nutzen, können zusätzliche Kosten anfallen.

7. Klicken Sie sich durch die nachfolgenden Seiten:

   • Akzeptieren Sie die Nutzungsbedingungen.
   • Fügen Sie keine Wiederherstellungsoptionen oder 2-Faktor-Authentifizierung hinzu, da dies nur ein temporäres Konto ist.
   • Melden Sie sich nicht für kostenlose Testversionen an.

Nach wenigen Augenblicken wird die Google Cloud Console in diesem Tab geöffnet.

Hinweis: Wenn Sie auf Google Cloud-Produkte und ‑Dienste zugreifen möchten, klicken Sie auf das Navigationsmenü oder geben Sie den Namen des Produkts oder Dienstes in das Feld Suchen ein.

Cloud Shell aktivieren

Cloud Shell ist eine virtuelle Maschine, auf der Entwicklertools installiert sind. Sie bietet ein Basisverzeichnis mit 5 GB nichtflüchtigem Speicher und läuft auf Google Cloud. Mit Cloud Shell erhalten Sie Befehlszeilenzugriff auf Ihre Google Cloud-Ressourcen.

1. Klicken Sie oben in der Google Cloud Console auf Cloud Shell aktivieren .

2. Klicken Sie sich durch die folgenden Fenster:

   • Fahren Sie mit dem Informationsfenster zu Cloud Shell fort.
   • Autorisieren Sie Cloud Shell, Ihre Anmeldedaten für Google Cloud API-Aufrufe zu verwenden.

Wenn eine Verbindung besteht, sind Sie bereits authentifiziert und das Projekt ist auf Project_ID, eingestellt. Die Ausgabe enthält eine Zeile, in der die Project_ID für diese Sitzung angegeben ist:

Ihr Cloud-Projekt in dieser Sitzung ist festgelegt als {{{project_0.project_id | "PROJECT_ID"}}}

gcloud ist das Befehlszeilentool für Google Cloud. Das Tool ist in Cloud Shell vorinstalliert und unterstützt die Tab-Vervollständigung.

3. (Optional) Sie können den aktiven Kontonamen mit diesem Befehl auflisten:

gcloud auth list

4. Klicken Sie auf Autorisieren.

Ausgabe:

ACTIVE: * ACCOUNT: {{{user_0.username | "ACCOUNT"}}} Um das aktive Konto festzulegen, führen Sie diesen Befehl aus: $ gcloud config set account `ACCOUNT`

5. (Optional) Sie können die Projekt-ID mit diesem Befehl auflisten:

gcloud config list project

Ausgabe:

[core] project = {{{project_0.project_id | "PROJECT_ID"}}} Hinweis: Die vollständige Dokumentation für gcloud finden Sie in Google Cloud in der Übersicht zur gcloud CLI.

Aufgabe 1: Vault installieren

1. Fügen Sie in Cloud Shell den GPG-Schlüssel von HashiCorp hinzu:

curl -fsSL https://apt.releases.hashicorp.com/gpg | sudo apt-key add - Hinweis: Eine eventuell angezeigte Warnung können Sie ignorieren.

2. Fügen Sie das offizielle HashiCorp-Linux-Repository hinzu:

sudo apt-add-repository "deb [arch=amd64] https://apt.releases.hashicorp.com $(lsb_release -cs) main"

3. Aktualisieren und installieren Sie Vault:

sudo apt-get update sudo apt-get install vault

Installation prüfen

Prüfen Sie nach der Installation von Vault, ob sie erfolgreich war. Stellen Sie dazu fest, ob die Vault-Binärdatei verfügbar ist.

• Führen Sie den Befehl vault aus, um die Installation zu prüfen:

vault

Die Hilfeausgabe sollte in etwa so aussehen:

Usage: vault <command> [args] Common commands: read Read data and retrieves secrets write Write data, configuration, and secrets delete Delete secrets and configuration list List data or secrets login Authenticate locally agent Start a Vault agent server Start a Vault server status Print seal and HA status unwrap Unwrap a wrapped secret Other commands: audit Interact with audit devices auth Interact with auth methods debug Runs the debug command kv Interact with Vault's Key-Value storage lease Interact with leases monitor Stream log messages from a Vault server namespace Interact with namespaces operator Perform operator-specific tasks path-help Retrieve API help for paths plugin Interact with Vault plugins and catalog policy Interact with policies print Prints runtime configurations secrets Interact with secrets engines ssh Initiate an SSH session token Interact with tokens

Aufgabe 2: Vault-Server starten

Nachdem Vault installiert ist, müssen Sie im nächsten Schritt einen Vault-Server starten.

Vault ist eine Client-Server-Anwendung. Der Vault-Server ist das einzige Element der Vault-Architektur, das mit dem Datenspeicher und den Backends interagiert. Alle über die Vault-Befehlszeile ausgeführten Vorgänge interagieren mit dem Server über eine TLS-Verbindung.

In diesem Lab starten Sie den Vault-Server im Entwicklungsmodus und interagieren mit ihm.

Für diesen Server im Entwicklermodus ist keine weitere Einrichtung erforderlich. Ihre lokale Vault-Befehlszeile wird authentifiziert, um mit ihm kommunizieren zu können. Das gibt Ihnen die Möglichkeit, auf einfache Weise mit Vault zu experimentieren oder eine Vault-Instanz für die Entwicklung zu starten. Im Entwicklermodus sind alle Funktionen von Vault verfügbar. Mit dem Flag -dev wird ein Großteil der Einrichtung übersprungen und es werden stattdessen unsichere Standardeinstellungen verwendet.

Warnung: Führen Sie niemals einen Server im Entwicklungsmodus in der Produktionsumgebung aus. Dieser Modus ist unsicher und bei jedem Neustart gehen Daten verloren, da sie ausschließlich im Arbeitsspeicher gespeichert werden. Er ist nur für die Entwicklung oder zum Experimentieren geeignet.

Entwicklungsserver starten

Starten Sie zuerst einen Vault-Entwicklungsserver. Dieser Entwicklungsserver ist ein integrierter, vorkonfigurierter Server, der nicht sehr sicher ist, aber hilfreich zum lokalen Ausprobieren von Vault.

1. Führen Sie den folgenden Befehl aus, um den Vault-Entwicklungsserver zu starten:

vault server -dev

Es sollte eine Ausgabe gemäß der Konfiguration Ihres Vault-Servers angezeigt werden. Beachten Sie, dass Werte für den Schlüssel zum Aufheben einer Versiegelung und das Root-Token angezeigt werden:

==> Vault server configuration: Api Address: http://127.0.0.1:8200 Cgo: disabled Cluster Address: https://127.0.0.1:8201 Listener 1: tcp (addr: "127.0.0.1:8200", cluster address: "127.0.0.1:8201", max_request_duration: "1m30s", max_request_size: "33554432", tls: "disabled") Log Level: info Mlock: supported: false, enabled: false Recovery Mode: false Storage: inmem Version: Vault v1.4.1 WARNING! dev mode is enabled! In this mode, Vault runs entirely in-memory and starts unsealed with a single unseal key. The root token is already authenticated to the CLI, so you can immediately begin using Vault. You may need to set the following environment variable: $ export VAULT_ADDR='http://127.0.0.1:8200' The unseal key and root token are displayed below in case you want to seal/unseal the Vault or re-authenticate. Unseal Key: 1+yv+v5mz+aSCK67X6slL3ECxb4UDL8ujWZU/ONBpn0= Root Token: s.XmpNPoi9sRhYtdKHaQhkHP6x Development mode should NOT be used in production installations! Hinweis: Der Entwicklungsserver speichert alle Daten im Arbeitsspeicher in verschlüsselter Form, überwacht localhost ohne TLS und hebt die Versiegelung automatisch auf. Außerdem werden der Schlüssel zum Aufheben einer Versiegelung und der Root-Zugriffsschlüssel angezeigt. Hinweis: Unsicherer Vorgang

Führen Sie niemals einen Vault-Entwicklungsserver in der Produktionsumgebung aus! Dieser Ansatz wird hier ausschließlich dazu verwendet, das Aufheben der Versiegelung für diese Demonstration zu vereinfachen.

Nachdem Sie den Vault-Entwicklungsserver gestartet haben, können Sie den Zugriff darauf einrichten.

2. Öffnen Sie einen neuen Tab in Cloud Shell.

3. Kopieren Sie den Exportbefehl VAULT_ADDR … aus der Terminalausgabe und führen Sie ihn aus. Damit wird der Vault-Client so konfiguriert, dass er mit dem Entwicklungsserver kommuniziert:

export VAULT_ADDR='http://127.0.0.1:8200'

Die Vault-Befehlszeile ermittelt anhand der Umgebungsvariable VAULT_ADDR, an welche Vault-Server Anfragen gesendet werden sollen.

Ausführung des Servers prüfen

• Prüfen Sie mit dem Befehl vault status, ob der Server ausgeführt wird:

vault status

Bei erfolgreicher Ausführung sollte die Ausgabe folgendermaßen aussehen:

$ vault status Key Value --- ----- Seal Type shamir Initialized true Sealed false Total Shares 1 Threshold 1 Version 1.13.2 Build Date 2023-04-25T13:02:50z Storage Type inmem Cluster Name vault-cluster-e2392b81 Cluster ID 48d7aba0-5416-a36b-2c27-0b256b222f57 HA Enabled false

Sehr gut. Sie haben Ihren ersten Vault-Entwicklungsserver gestartet. Sie können jetzt mit dem nächsten Abschnitt fortfahren. Dort erfahren Sie, wie Sie Vault-Richtlinien erstellen.

Aufgabe 3: Vault-Richtlinien

Vault erstellt während der Initialisierung eine root-Richtlinie. Mit der root-Richtlinie können alle Vorgänge für alle Pfade ausgeführt werden. Diese Richtlinie wird dem root-Token zugewiesen, das nach Abschluss der Initialisierung angezeigt wird. Dadurch wird ein erster Superuser bereitgestellt, mit dem Sie Secrets Engines aktivieren, Richtlinien definieren und Authentifizierungsmethoden konfigurieren können.

Vault erstellt auch eine default-Richtlinie. Diese Standardrichtlinie definiert eine Reihe von Funktionen, mit denen ein Token Informationen über sich abrufen und sich verwalten kann. Die Richtlinie wird auch dem root-Token zugewiesen und ist standardmäßig an alle Tokens angehängt.

Richtliniensyntax

Richtlinien werden in HCL oder JSON erstellt und legen fest, auf welche Pfade in Vault Nutzerinnen und Nutzer oder Computer zugreifen können. Eine Richtlinie definiert eine Liste von Pfaden. Jeder Pfad gibt die zulässigen Funktionen an. Die Verwendung von Funktionen für einen Pfad muss explizit gewährt werden, da Vault standardmäßig den Zugriff auf Pfade verweigert. Damit soll gewährleistet werden, dass es standardmäßig sicher ist.

Das grundlegende Format einer Richtlinie sieht folgendermaßen aus:

path "<path>" { capabilities = ["list of capabilities"] }

Im Folgenden ist eine sehr einfache Richtlinie aufgeführt, die Berechtigungen für Lesefunktionen für den Pfad secret/foo gewährt:

path "secret/foo" { capabilities = ["read"] }

Wenn diese Richtlinie einem Token zugewiesen wird, kann das Token aus secret/foo lesen. Mit dem Token ist jedoch nicht möglich, secret/foo zu aktualisieren oder zu löschen, da dafür keine Berechtigung vorhanden ist. Da Richtlinien den Zugriff standardmäßig ablehnen, hat das Token keinen weiteren Zugriff in Vault. Das bedeutet, dass eine leere Vault-Richtlinie keine Berechtigung im System gewährt.

Funktionen

Eine Richtlinie definiert einen oder mehrere Pfade sowie eine Liste zulässiger Funktionen. Jeder Pfad muss eine oder mehrere Funktionen festlegen, die eine detailgenaue Steuerung der zulässigen (oder verweigerten) Vorgänge ermöglichen. Wie Sie in den Beispielen unten sehen, werden Funktionen immer als Liste von Strings angegeben, auch wenn es nur eine Funktion gibt. Die meisten dieser Funktionen sind den HTTP-Verben zugeordnet, die von der Vault API unterstützt werden. In der Liste ist Folgendes enthalten:

Richtlinienfunktion	Zugehörige HTTP-Verben
create	POST/PUT
read	GET
update	POST/PUT
delete	DELETE
list	LIST
patch	PATCH
sudo	-
deny	-

Die sudo-Funktion ermöglicht den Zugriff auf Pfade, die durch Root-Berechtigungen geschützt sind (siehe Abschnitt Root-geschützte Endpunkte in der Anleitung). Die Funktion deny deaktiviert den Zugriff auf den Pfad. Bei Kombination mit anderen Funktionen hat sie immer Vorrang.

Beispiele für Richtlinien

Eine detailliertere Richtlinie, die allen Zugriff auf secret/* gewährt, sieht z. B. so aus:

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

Wenn Sie weitere Einschränkungen definieren möchten, können Sie die folgende deny-Funktion hinzufügen:

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

Obwohl Sie secret/* zugelassen haben, verhindert diese zusätzliche Zeile oben den Zugriff auf secret/super-secret explizit. Explizite Einschränkungen haben Vorrang vor erteilten Berechtigungen.

In Richtlinien können auch zulässige, unzulässige und erforderliche Parameter angegeben werden. Der Schlüssel secret/restricted darf hier nur foo (mit einem beliebigen Wert) und bar (mit dem Wert zip oder zap) enthalten.

path "secret/restricted" { capabilities = ["create"] allowed_parameters = { "foo" = [] "bar" = ["zip", "zap"] } }

Richtlinien verwenden den pfadbasierten Abgleich, um zu prüfen, welche Funktionen für eine Anfrage gelten. Ein Richtlinienpfad kann einen genauen Pfad für den Abgleich oder ein Glob-Muster festlegen, das Vault anweist, einen Präfixabgleich zu verwenden.

Diese Richtlinie erlaubt beispielsweise nur das Lesen von secret/foo oder secret/foo/bar.

path "secret/foo" { capabilities = ["read"] }

Außerdem erlaubt diese Richtlinie das Lesen aller Daten unterhalb von secret/bar. Ein angehängtes Token kann secret/bar/zip, secret/bar/zip/zap, jedoch nicht secret/bars/zip lesen.

path "secret/bar/*" { capabilities = ["read"] }

Darüber hinaus erlaubt diese Richtlinie den Lesezugriff auf alle Pfade, die mit zip- beginnen. Ein angehängtes Token kann secret/zip-zap oder secret/zip-zap/zong lesen, aber nicht secret/zip/zap.

path "secret/zip-*" { capabilities = ["read"] }

Außerdem kann mit + eine beliebige Anzahl an Zeichen innerhalb eines einzelnen Pfadsegments angegeben werden. Mit der folgenden Zeile ist z. B. das Lesen des Pfads teamb unter jedem Pfad der obersten Ebene unter secret/ möglich.

path "secret/+/teamb" { capabilities = ["read"] }

Die nächste Zeile erlaubt das Lesen von secret/foo/bar/teamb, secret/bar/foo/teamb usw.

path "secret/+/+/teamb" { capabilities = ["read"] }

Wie Sie sehen, ähnelt die Vault-Architektur einem Dateisystem. Jede Aktion in Vault hat einen entsprechenden Pfad und eine entsprechende Funktion – auch die internen Endpunkte der Kernkonfiguration von Vault befinden sich unter dem Pfad sys/. Richtlinien definieren den Zugriff auf diese Pfade und Funktionen. Dadurch wird der Zugriff eines Tokens auf Anmeldedaten in Vault gesteuert.

Richtlinienvorlagen

Die Richtliniensyntax ermöglicht in einigen Richtlinienstrings die Verwendung von Variablen für Werte, die für das Token verfügbar sind. Derzeit können Identitätsinformationen eingefügt werden, wobei das Einfügen aktuell von Pfadschlüsseln in Richtlinien ermöglicht wird. Sie müssen sich jetzt noch keine Gedanken über Entitäten oder Aliase machen. Diese werden hier nur für eine spätere Referenz aufgeführt.

Parameter

Name	Beschreibung
identity.entity.id	ID der Entität
identity.entity.name	Name der Entität
identity.entity.metadata.<metadata key>	Metadaten, die mit der Entität für den angegebenen Schlüssel verknüpft sind
identity.entity.aliases.<mount accessor>.id	ID des Entitätsalias für die angegebene Bereitstellung
identity.entity.aliases.<mount accessor>.name	Aliasname der Entität für die angegebene Bereitstellung
identity.entity.aliases.<mount accessor>.metadata.<metadata key>	Metadaten, die mit dem Alias für die angegebene Bereitstellung und dem Metadatenschlüssel verknüpft sind
identity.entity.aliases.<mount accessor>.custom_metadata.<custom_metadata key>	Benutzerdefinierte Metadaten, die mit dem Alias für die angegebene Bereitstellung und dem benutzerdefinierten Metadatenschlüssel verknüpft sind
identity.groups.ids.<group id>.name	Der Gruppenname für die angegebene Gruppen-ID
identity.groups.names.<group name>.id	Die Gruppen-ID für den angegebenen Gruppennamen
identity.groups.ids.<group id>.metadata.<metadata key>	Metadaten, die mit der Gruppe für den angegebenen Schlüssel verknüpft sind
identity.groups.names.<group name>.metadata.<metadata key>	Metadaten, die mit der Gruppe für den angegebenen Schlüssel verknüpft sind

Beispiele

Mit der folgenden Richtlinie wird ein Abschnitt der KVv2 Secrets Engine für eine bestimmte Nutzerin bzw. für einen bestimmten Nutzer erstellt:

path "secret/data/{{identity.entity.id}}/*" { capabilities = ["create", "update", "read", "delete"] } path "secret/metadata/{{identity.entity.id}}/*" { capabilities = ["list"] }

Weitere Informationen zu Richtlinienvorlagen finden Sie in der Dokumentation zu Richtlinienvorlagen.

Hinweis: Verwenden Sie bei der Entwicklung von Richtlinienvorlagen nach Möglichkeit IDs. Jede ID wird nur einmal für eine Nutzerin oder einen Nutzer vergeben, während sich Namen im Laufe der Zeit ändern und wiederverwendet werden können. So ist gewährleistet, dass die Richtlinie der gewünschten Entität oder Gruppe zugeordnet wird, wenn ein bestimmter Nutzer- oder Gruppenname geändert wird.

Integrierte Richtlinienfunktionen prüfen

Sie wissen nun, wie Richtlinien erstellt werden. Sehen wir uns jetzt kurz die Funktionen der Richtlinien root und default an.

1. Führen Sie im geöffneten Cloud Shell-Tab den folgenden Befehl aus, um sich mit Ihrem Root-Token in Vault anzumelden:

vault login token=<your root token>

Es sollte folgende Ausgabe angezeigt werden:

Success! You are now authenticated. The token information displayed below is already stored in the token helper. You do NOT need to run "vault login" again. Future Vault requests will automatically use this token. Key Value --- ----- token s.mCWmZyVNi6ZDU7HSq7vQXwvj token_accessor nFDgTnm7FYCHNLSERwiVsbWf token_duration ∞ token_renewable false token_policies ["root"] identity_policies [] policies ["root"] Hinweis: Die angehängte Richtlinie ist die root-Richtlinie.

2. Da die Richtlinie „root“ uneingeschränkten Zugriff auf Vault gewährt, können Sie mit einem Befehl prüfen, ob dies der Fall ist:

vault secrets list

Ihre Ausgabe sollte in etwa so aussehen:

Path Type Accessor Description ---- ---- -------- ----------- cubbyhole/ cubbyhole cubbyhole_f0f2e28e per-token private secret storage identity/ identity identity_a554d41f identity store secret/ kv kv_ca28f047 key/value secret storage sys/ system system_1a7dcf93 system endpoints..

Als Nächstes versuchen Sie, den gleichen Befehl als Nutzerin oder Nutzer auszuführen, der bzw. dem nur die Richtlinie default zugewiesen ist.

3. Aktivieren Sie zuerst die Authentifizierungsmethode userpass und erstellen Sie eine neue Nutzerin bzw. einen neuen Nutzer:

vault auth enable userpass vault write auth/userpass/users/example-user password=password!

4. Melden Sie sich als Nächstes mit dem neu erstellten Nutzerkonto in Vault an:

vault login -method=userpass username=example-user password=password!

Es sollte Folgendes angezeigt werden:

Success! You are now authenticated. The token information displayed below is already stored in the token helper. You do NOT need to run "vault login" again. Future Vault requests will automatically use this token. Key Value --- ----- token s.Ov9GkScxp5AYDjzmbdHNN4r0 token_accessor UewGCCotUMjccmD1EjssgHqf token_duration 768h token_renewable true token_policies ["default"] identity_policies [] policies ["default"] token_meta_username example-user Hinweis: Die angehängte Richtlinie ist die Richtlinie default.

5. Führen Sie den gleichen Befehl wie zuvor aus, um die Richtlinienfunktionen zu prüfen:

vault secrets list

Es sollte die folgende Fehlermeldung angezeigt werden:

Error listing secrets engines: Error making API request. URL: GET http://127.0.0.1:8200/v1/sys/mounts Code: 403. Errors: * 1 error occurred: * permission denied

Wie Sie hier sehen, sendet Vault eine GET-Anfrage an die API für den Pfad sys/mounts. Sie erhalten die Meldung, dass die Berechtigung verweigert wurde, und können also nicht auf den Pfad zugreifen und die Secrets Engines auflisten. Jetzt ist es an der Zeit, Ihre erste Richtlinie zu erstellen, um Zugriff auf diesen Pfad zu bekommen und die Secrets Engines aufzulisten.

Aufgabe 4: Richtlinie erstellen

Da Vault den Zugriff auf Secrets in verteilten Infrastrukturen und Anwendungen zentral sichert, speichert und steuert, ist es wichtig, das die Berechtigungen kontrolliert werden, bevor Nutzerinnen, Nutzer oder Maschinen Zugriff erhalten.

Dafür müssen die Verwendung der Richtlinie „root“ eingeschränkt und detailgenaue Richtlinien erstellt werden, um das Prinzip der geringsten Berechtigung anzuwenden. Wenn eine Anwendung beispielsweise Google Cloud-Anmeldedaten aus Vault abruft, können Sie eine Richtlinie erstellen, die das Lesen aus der Secrets Engine von Google Cloud erlaubt, aber nicht das Löschen oder andere Aktionen.

Richtlinien werden an Token und Rollen angehängt, um Clientberechtigungen in Vault durchzusetzen. Sie kennen nun die Syntax für die Definition von Richtlinien und können Ihre erste Vault-Richtlinie erstellen.

In der Web-UI von Vault anmelden

1. Klicken Sie zuerst in der Cloud Shell-Symbolleiste auf das Symbol für Webvorschau.

2. Klicken Sie auf Port ändern.

3. Legen Sie als neue Portnummer 8200 fest und klicken Sie auf Ändern und Vorschau.

4. Sie werden daraufhin automatisch zur Vault-Anmeldeseite weitergeleitet.

5. Geben Sie das Root-Token ein, das Sie zuvor im Lab gespeichert haben, und klicken Sie auf Anmelden.

Ihr Vault-Entwicklungsserver sollte in etwa so aussehen:

Sie sind jetzt in der Web-UI des Entwicklungsservers angemeldet und können mit dem nächsten Abschnitt fortfahren.

Neue Richtlinie erstellen

1. Klicken Sie auf der Startseite auf Zugriffssteuerung. Es sollten die ACL-Richtlinien default und root angezeigt werden.

2. Klicken Sie auf ACL-Richtlinie erstellen.

3. Geben Sie der Richtlinie den Namen demo-policy.

Sie können jetzt mit dem Erstellen Ihrer Richtlinie beginnen. Im vorherigen Abschnitt konnten Sie nicht auf den Pfad sys/mounts zugreifen, um die Secrets Engines zu lesen. Diese Zugriffsmöglichkeit fügen Sie jetzt hinzu.

4. Wählen Sie unter Richtlinienregeln die Option Code-Editor aus und fügen Sie den folgenden Platzhaltercode hinzu:

path "path" { capabilities = [""] }

5. Ersetzen Sie dann path mit dem Pfad sys/mounts, auf den Sie zuvor zugreifen wollten:

path "sys/mounts" { capabilities = [""] }

6. Als Nächstes fügen Sie eine Funktion hinzu. Da Vault versucht, einen GET-API-Aufruf für diesen Pfad auszuführen, benötigen Sie die Funktion read. Fügen Sie der Liste der Funktionen read hinzu:

path "sys/mounts" { capabilities = ["read"] }

Ihre Richtlinie sollte in etwa so aussehen:

7. Klicken Sie auf Richtlinie erstellen.

Jetzt müssen Sie diese Richtlinie mit dem zuvor erstellten Nutzerkonto example-user verknüpfen.

8. Klicken Sie auf Zurück zur Hauptnavigation.

9. Klicken Sie im linken Bereich auf Zugriff > Authentifizierungsmethoden und dann auf userpass.

10. Klicken Sie auf das Dreipunkt-Menü neben example-user und wählen Sie Nutzer bearbeiten aus.

11. Klicken Sie unter dem Passwortfeld auf Tokens, um das Untermenü zu öffnen.

12. Fügen Sie unter Richtlinien des generierten Tokens die soeben erstellte Richtlinie (demo-policy) hinzu und klicken Sie auf Hinzufügen.

13. Klicken Sie auf Speichern.

Sehr gut. Sie haben eine neue Richtlinie erstellt und sie mit example-user verknüpft.

14. Kehren Sie zu Cloud Shell zurück und führen Sie den folgenden Befehl noch einmal aus:

vault secrets list

Es wird der gleiche Fehler wie zuvor angezeigt:

Error listing secrets engines: Error making API request. URL: GET http://127.0.0.1:8200/v1/sys/mounts Code: 403. Errors: * 1 error occurred: * permission denied

Warum ist der Fehler aufgetreten, nachdem Sie die Richtlinie der Nutzerin bzw. dem Nutzer hinzugefügt haben? Wenn Sie eine neue Richtlinie mit einer Nutzerin oder einem Nutzer verknüpfen, wird diese Richtlinie nicht mit dem vorhandenen Token für diese Nutzerin oder diesen Nutzer verknüpft. Um das zu ermöglichen, müssen Sie ein neues Token für diese Nutzerin bzw. diesen Nutzer generieren, damit die neue Richtlinie an dieses Token angehängt werden kann.

15. Führen Sie den folgenden Befehl aus, um sich anzumelden und ein neues Token für example-user zu generieren:

vault login -method=userpass username=example-user password=password! Hinweis: Die Ausgabe sollte ein neues Token enthalten. Beachten Sie, dass jetzt die Richtlinien default und demo-policy angehängt sind. Success! You are now authenticated. The token information displayed below is already stored in the token helper. You do NOT need to run "vault login" again. Future Vault requests will automatically use this token. Key Value --- ----- token s.7AVelOPORi1zhjH5iLototw7 token_accessor H1ee2gTXzTXUU9ptpU3ailnJ token_duration 768h token_renewable true token_policies ["default" "demo-policy"] identity_policies [] policies ["default" "demo-policy"] token_meta_username example-user

16. Versuchen Sie nun noch einmal, die Secrets Engines aufzulisten:

vault secrets list

Ihre Ausgabe sollte jetzt in etwa so aussehen:

Path Type Accessor Description ---- ---- -------- ----------- cubbyhole/ cubbyhole cubbyhole_76cb59ae per-token private secret storage identity/ identity identity_7fa27e52 identity store secret/ kv kv_f6e83366 key/value secret storage sys/ system system_414d50aa system endpoints..

17. Sie können die Funktionen des Tokens auch mit dem Befehl vault token capabilities prüfen. Führen Sie den folgenden Befehl aus, um Ihre Richtlinie im Pfad sys/mounts zu überprüfen:

vault token capabilities <your token> sys/mounts

Es sollte die folgende Ausgabe angezeigt werden:

read

18. Prüfen Sie als Nächstes die Tokenfunktionen für den Pfad sys/policies/acl:

vault token capabilities <your token> sys/policies/acl

Es sollte die folgende Ausgabe angezeigt werden:

deny

19. Führen Sie zur Überprüfung den folgenden Befehl aus, um die Richtlinien aufzulisten:

vault policy list

Es sollte die folgende Fehlermeldung angezeigt werden:

Error listing policies: Error making API request. URL: GET http://127.0.0.1:8200/v1/sys/policies/acl?list=trueCode: 403. Errors: * 1 error occurred: * permission denied

Wie Sie hier sehen, erhalten Sie eine Fehlermeldung wegen einer verweigerte Berechtigung für eine GET API-Anfrage für den Pfad sys/policies/acl. Beachten Sie auch den Zusatz list=true im Pfad. Diese Funktion müssen Sie ebenfalls hinzufügen. Wir wollen nun das Problem durch Aktualisierung der vorhandenen Richtlinie beheben.

20. Kehren Sie zur Richtlinie demo-policy zurück, die Sie in der Vault-Benutzeroberfläche erstellt haben.

21. Klicken Sie auf Richtlinie bearbeiten.

22. Fügen Sie im Feld Richtlinie den folgenden Platzhaltercode unter der erstellten Richtlinie ein:

path "path" { capabilities = [""] }

23. Ersetzen Sie zuerst wieder path mit dem Pfad sys/policies/acl, auf den Sie zugreifen wollten:

path "sys/policies/acl" { capabilities = [""] }

24. Dann fügen Sie die Funktion hinzu. Da Vault versucht, einen GET API-Aufruf für diesen Pfad auszuführen, müssen Sie wieder die Funktion read hinzufügen. Außerdem wurde bei diesem Versuch list=true an die URL übergeben. Sie müssen diese Funktion also ebenfalls hinzufügen.

path "sys/policies/acl" { capabilities = ["read", "list"] }

Die aktualisierte Richtlinie sollte nun in etwa so aussehen:

25. Klicken Sie auf Speichern.

26. Kehren Sie zu Cloud Shell zurück und führen Sie den folgenden Befehl noch einmal aus:

vault policy list

Die Ausgabe sollte jetzt so aussehen:

default default-ceiling demo-policy root

27. Führen Sie den folgenden Befehl aus, um die Werte der Richtlinien in eine Textdatei zu kopieren:

vault policy list > policies.txt

28. Prüfen Sie abschließend noch einmal die Tokenfunktionen für den Pfad sys/policies/acl:

vault token capabilities <your token> sys/policies/acl

Es sollte die folgende Ausgabe angezeigt werden:

list, read

29. Führen Sie den folgenden Befehl aus, um die Werte der Richtlinien in eine Textdatei zu kopieren. Ersetzen Sie <your token> durch den Wert Ihres Tokens:

vault token capabilities <your token> sys/policies/acl > token_capabilities.txt

30. Führen Sie die folgenden Befehle aus, um die Textdateien policies und token_capabilities in einen zuvor erstellten Cloud Storage-Bucket zu kopieren und Ihren Fortschritt zu verfolgen:

export PROJECT_ID=$(gcloud config get-value project) gcloud storage cp *.txt gs://$PROJECT_ID

Sie sehen, dass die Änderungen übernommen wurden, ohne dass ein neues Token erstellt werden musste, nachdem Sie die mit der Nutzerin bzw. dem Nutzer verknüpfte vorhandene Richtlinie geändert haben. Das liegt daran, dass der Inhalt von Richtlinien bei jeder Verwendung des Tokens in Echtzeit ausgewertet wird. Wird eine Richtlinie geändert, werden dann die modifizierten Regeln beim nächsten Aufruf für Vault mit einem Token, an das diese Richtlinie angehängt ist, durchgesetzt.

Sehr gut. Sie haben eine Richtlinie erstellt, die Lesezugriff auf den Pfad sys/mounts gewährt, und diese Richtlinie mit einer Nutzerin bzw. einem Nutzer verknüpft. Anschließend haben Sie eine zusätzliche Richtlinie hinzugefügt, um Lese- und Listenzugriff auf den Pfad sys/policies zu gewähren.

Klicken Sie auf Fortschritt prüfen. Richtlinien erstellen

Aufgabe 5: Richtlinien verwalten

Richtlinien können in einem beliebigen Editor erstellt werden. Sie haben die Möglichkeit, diese in HCL oder in JSON zu schreiben, die Syntax ist oben detailliert beschrieben. Nach dem Speichern müssen die Richtlinien in Vault hochgeladen werden, damit sie verwendet werden können.

Im vorherigen Abschnitt haben Sie mit der Benutzeroberfläche eine Richtlinie erstellt und verwaltet. In diesem Abschnitt werden die Befehlszeilenbefehle zur Verwaltung von Richtlinien behandelt.

• Führen Sie als Erstes den folgenden Befehl in Cloud Shell aus, um sich mit Ihrem Root-Token in Vault anzumelden:

vault login <your root token>

Richtlinien auflisten

• Führen Sie den folgenden Befehl aus, um alle in Vault registrierten Richtlinien aufzulisten:

vault read sys/policy

Es sollte folgende Ausgabe angezeigt werden:

Key Value --- ----- keys [default demo-policy root] policies [default demo-policy root

Richtlinien erstellen

Richtlinien können über die Befehlszeile, die Benutzeroberfläche oder die API erstellt (hochgeladen) werden. Im vorherigen Abschnitt haben Sie die HCL-Datei ganz einfach über die Benutzeroberfläche erstellt.

Mit dem folgenden Befehl legen Sie eine neue Richtlinie in Vault an:

vault policy write policy-name policy-file.hcl

1. Sie können dies überprüfen, indem Sie zuerst mit dem folgenden Befehl eine einfache Richtliniendatei erstellen:

tee example-policy.hcl <<EOF # List, create, update, and delete key/value secrets path "secret/*" { capabilities = ["create", "read", "update", "delete", "list", "sudo"] } # Manage secrets engines path "sys/mounts/*" { capabilities = ["create", "read", "update", "delete", "list", "sudo"] } # List existing secrets engines. path "sys/mounts" { capabilities = ["read"] } EOF

2. Prüfen Sie, ob die Datei korrekt erstellt wurde:

cat example-policy.hcl

3. Legen Sie nun mit dem Befehl vault policy write eine neue Richtlinie mit dem Namen example-policy an:

vault policy write example-policy example-policy.hcl

Es sollte dann die folgende Ausgabe angezeigt werden:

Success! Uploaded policy: example-policy

In diesem Beispiel lautet der Name der Richtlinie „example-policy“. Sie können sich diesen Namen als Zeiger oder Symlink auf die Richtlinien-ACLs vorstellen. Tokens werden Richtlinien anhand ihres Namens angehängt und anschließend dem Regelsatz für diesen Namen zugeordnet.

Richtlinien aktualisieren

Vorhandene Richtlinien können aktualisiert werden, wenn Berechtigungen über die Befehlszeile oder die API geändert werden sollen. Wenn Sie eine vorhandene Richtlinie in Vault aktualisieren möchten, gehen Sie genauso vor wie beim Erstellen einer Richtlinie, verwenden aber einen vorhandenen Richtliniennamen.

1. Führen Sie zuerst den folgenden Befehl aus, um Ihre vorhandene Richtliniendatei zu aktualisieren und zu überschreiben, damit Sie Authentifizierungsmethoden auflisten können:

tee example-policy.hcl <<EOF # List, create, update, and delete key/value secrets path "secret/*" { capabilities = ["create", "read", "update", "delete", "list", "sudo"] } # Manage secrets engines path "sys/mounts/*" { capabilities = ["create", "read", "update", "delete", "list", "sudo"] } # List existing secrets engines. path "sys/mounts" { capabilities = ["read"] } # List auth methods path "sys/auth" { capabilities = ["read"] } EOF

2. Prüfen Sie, ob die Datei korrekt erstellt wurde:

cat example-policy.hcl

3. Aktualisieren Sie Ihre Richtlinie:

vault write sys/policy/example-policy policy=@example-policy.hcl

Sehr gut. Sie haben eine Richtlinie mithilfe der Befehlszeile aktualisiert.

4. Führen Sie den folgenden Befehl aus, um die Richtliniendatei in einen zuvor erstellten Cloud Storage-Bucket zu kopieren, damit Sie den Fortschritt verfolgen können:

gcloud storage cp example-policy.hcl gs://$PROJECT_ID

Klicken Sie auf Fortschritt prüfen. Richtlinien mit Befehlszeilenbefehlen erstellen und verwalten

Richtlinien löschen

Vorhandene Richtlinien können über die Befehlszeile, die Benutzeroberfläche oder die API gelöscht werden. Für das Löschen einer Richtlinie muss folgender Befehl ausgeführt werden:

vault delete sys/policy/policy-name

1. Wir wenden diesen Befehl nun konkret an. Führen Sie den folgenden Befehl aus, um die eben erstellte Richtlinie zu löschen:

vault delete sys/policy/example-policy

Nach erfolgreicher Ausführung sollte die folgende Ausgabe angezeigt werden:

Success! Data deleted (if it existed) at: sys/policy/example-policy

2. Listen Sie Ihre Richtlinien mit dem folgenden Befehl auf:

vault policy list

Es sollte folgende Ausgabe angezeigt werden:

default default-ceiling demo-policy root

Sehr gut. Sie haben example-policy nun gelöscht.

Hinweis: Dies ist ein idempotenter Vorgang. Vault gibt keine Fehlermeldung aus, wenn eine Richtlinie gelöscht werden soll, die nicht vorhanden ist.

Aufgabe 6: Richtlinien verknüpfen

Vault kann mehrere Richtlinien basierend auf einer Autorisierung automatisch mit einem Token verknüpfen. Diese Konfiguration unterscheidet sich zwischen verschiedenen Authentifizierungs-Backends erheblich. Zur Vereinfachung wird in diesem Beispiel die integrierte Authentifizierungsmethode „userpass“ von Vault verwendet.

1. Führen Sie den folgenden Befehl aus, um die Nutzerin bzw. den Nutzer firstname-lastname in Vault mit einer Liste verknüpfter Richtlinien anzulegen:

vault write auth/userpass/users/firstname-lastname \ password="s3cr3t!" \ policies="default, demo-policy" Success! Data written to: auth/userpass/users/firstname-lastname

Dadurch wird eine Authentifizierungszuordnung zur Richtlinie erstellt. Wenn sich die Nutzerin oder der Nutzer dann erfolgreich bei Vault authentifiziert hat, erhält sie oder er ein Token, an das die Liste der Richtlinien angehängt ist.

2. Authentifizieren Sie sich bei Vault, indem Sie Folgendes ausführen:

vault login -method="userpass" username="firstname-lastname" password="s3cr3t!"

Es sollte folgende Ausgabe angezeigt werden:

Key Value --- ----- token s.XnRsinhsokVUiN7XbsnyCOEC token_accessor JFErk5Rgb7vtW47CJjY2OCsF token_duration 768h token_renewable true token_policies ["default" "demo-policy"] identity_policies [] policies ["default" "demo-policy"] token_meta_username firstname-lastname

Da die angegebenen Informationen korrekt sind, generiert Vault ein Token, weist dem Token die Liste der konfigurierten Richtlinien zu und gibt das Token an die authentifizierte Nutzerin bzw. an den authentifizierten Nutzer zurück.

Tokens

Für Tokens gibt es zwei Arten von Richtlinien: Identitätsrichtlinien, die auf der Grundlage der Entität und ihrer Gruppen berechnet werden, sowie Tokenrichtlinien, die entweder auf der Grundlage der Anmeldemethode definiert werden oder, im Fall der expliziten Tokenerstellung über die API, für die Tokenerstellung eingegeben werden. Im Folgenden geht es ausschließlich um Tokenrichtlinien. Die Identitätsrichtlinien eines Tokens können nur durch Änderung der zugrunde liegenden Entitäten, Gruppen und Gruppenmitgliedschaften modifiziert werden.

1. Melden Sie sich zuerst mit Ihrem Root-Token wieder in Vault an:

vault login <your root token>

2. Tokens werden bei der Erstellung mit ihren Richtlinien verknüpft. Führen Sie den folgenden Befehl aus, um ein Token mit den Richtlinien dev-readonly und logs zu erstellen:

vault token create -policy=dev-readonly -policy=logs

Es sollte folgende Ausgabe angezeigt werden:

Key Value --- ----- token s.gKRV6vzFmpdJ9iwvPfzNjAuI token_accessor S4jfdYvy8jQP7GGDa947CBlT token_duration 768h token_renewable true token_policies ["default" "dev-readonly" "logs"] identity_policies [] policies ["default" "dev-readonly" "logs"] Hinweis: Sie können die Warnungen, dass die Richtlinien nicht vorhanden sind, ignorieren, da Sie diese noch nicht erstellt haben.

Normalerweise können nur die Richtlinien aus in den Tokenrichtlinien des aktuellen Tokens (d. h. des übergeordneten Tokens des neuen Tokens) angegeben werden. Root-Nutzerinnen und -Nutzer können aber beliebige Richtlinien zuweisen.

Die mit einem Token verknüpften Richtlinien können nach der Ausgabe des Tokens nicht mehr geändert werden. Für einen neuen Satz von Richtlinien muss das Token widerrufen und ein neues Token angefordert werden.

Der Inhalt von Richtlinien wird jedoch in Echtzeit ausgewertet, wenn das Token verwendet wird. Wird eine Richtlinie geändert, werden dann die modifizierten Regeln beim nächsten Aufruf für Vault mit einem Token, an das diese Richtlinie angehängt ist, durchgesetzt.

Aufgabe 7: Richtlinien für Secrets

In diesem Abschnitt erstellen Sie Vault-Richtlinien, um Nutzerinnen und Nutzern unterschiedliche Zugriffsebenen in Vault zuzuweisen, und testen diese.

• Erstellen Sie zuerst in Cloud Shell mehrere unterschiedliche Nutzerinnen und Nutzer mit unterschiedlichen Richtlinien:

vault write auth/userpass/users/admin \ password="admin123" \ policies="admin" vault write auth/userpass/users/app-dev \ password="appdev123" \ policies="appdev" vault write auth/userpass/users/security \ password="security123" \ policies="security"

Nachdem Sie mehrere neue Nutzerinnen und Nutzer erstellt haben, legen Sie nun die Richtlinien an, die Sie bereits mit ihnen verknüpft haben. Sie beginnen mit der Richtlinie admin, die kompletten Zugriff auf alle Secrets in Vault haben soll.

Administratorrichtlinie erstellen

In diesem Lab muss eine admin-Nutzerin bzw. ein entsprechender Nutzer folgende Aktionen durchführen können:

• Systemdiagnose lesen
• ACL-Richtlinien in Vault erstellen und verwalten
• Authentifizierungsmethoden umfassend in Vault aktivieren und verwalten
• Schlüssel/Wert-Paar-Secrets-Engine verwalten, die unter secret/ aktiviert ist

1. Rufen Sie im linken Bereich der Vault-Benutzeroberfläche ACL-Richtlinien auf. Es sollten die Richtlinien default, default-ceiling, demo-policy und root angezeigt werden.

2. Klicken Sie auf ACL-Richtlinie erstellen.

3. Geben Sie der Richtlinie den Namen admin.

4. Wählen Sie unter Richtlinienregeln die Option Code-Editor aus und fügen Sie den folgenden Richtliniencode hinzu:

# Read system health check path "sys/health" { capabilities = ["read", "sudo"] } # Create and manage ACL policies broadly across Vault # List existing policies path "sys/policies/acl" { capabilities = ["list"] } # Create and manage ACL policies path "sys/policies/acl/*" { capabilities = ["create", "read", "update", "delete", "list", "sudo"] } # Enable and manage authentication methods broadly across Vault # Manage auth methods broadly across Vault path "auth/*" { capabilities = ["create", "read", "update", "delete", "list", "sudo"] } # Create, update, and delete auth methods path "sys/auth/*" { capabilities = ["create", "update", "delete", "sudo"] } # List auth methods path "sys/auth" { capabilities = ["read"] } # Enable and manage the key/value secrets engine at `secret/` path # List, create, update, and delete key/value secrets path "secret/*" { capabilities = ["create", "read", "update", "delete", "list", "sudo"] } # Manage secrets engines path "sys/mounts/*" { capabilities = ["create", "read", "update", "delete", "list", "sudo"] } # List existing secrets engines. path "sys/mounts" { capabilities = ["read"] }

Ihre Richtlinie sollte in etwa so aussehen:

5. Klicken Sie auf Richtlinie erstellen.

Richtlinie für die Anwendungsentwicklung (appdev) erstellen

Für dieses Lab müssen appdev-Nutzerinnen bzw. entsprechende Nutzer Folgendes ausführen können:

• Secrets Engines erstellen, lesen und aktualisieren
• Schlüssel/Wert-Secrets-Engine verwalten, die unter dem Pfad secret/appdev/ aktiviert ist

1. Kehren Sie zur Seite ACL-Richtlinien zurück.

2. Klicken Sie auf ACL-Richtlinie erstellen.

3. Geben Sie der Richtlinie den Namen appdev.

4. Wählen Sie unter Richtlinienregeln die Option Code-Editor aus und fügen Sie den folgenden Richtliniencode hinzu:

# List, create, update, and delete key/value secrets path "secret/+/appdev/*" { capabilities = ["create", "read", "update", "delete", "list", "sudo"] } # Create, read, and update secrets engines path "sys/mounts/*" { capabilities = ["create", "read", "update"] } # List existing secrets engines. path "sys/mounts" { capabilities = ["read"] }

5. Klicken Sie auf Richtlinie erstellen.

Sicherheitsrichtlinie erstellen

Für dieses Lab müssen security-Nutzerinnen und -Nutzer folgende Aktionen ausführen können:

• ACL-Richtlinien in Vault erstellen und verwalten
• Secrets Engines verwalten
• Schlüssel/Wert-Paar-Secrets-Engine verwalten, die unter secret/ aktiviert ist
• Hinweis: Sie sollen aber keinen Zugriff zum Lesen oder Auflisten von Secrets im Pfad secret/admin haben.

1. Kehren Sie zur Seite ACL-Richtlinien zurück.

2. Klicken Sie auf ACL-Richtlinie erstellen.

3. Geben Sie der Richtlinie den Namen security.

4. Wählen Sie unter Richtlinienregeln die Option Code-Editor aus und fügen Sie den folgenden Richtliniencode hinzu:

# List existing policies path "sys/policies/acl" { capabilities = ["list"] } # Create and manage ACL policies path "sys/policies/acl/*" { capabilities = ["create", "read", "update", "delete", "list", "sudo"] } # Manage secrets engines path "sys/mounts/*" { capabilities = ["create", "read", "update", "delete", "list", "sudo"] } # List existing secrets engines. path "sys/mounts" { capabilities = ["read"] } # List, create, update, and delete key/value secrets path "secret/*" { capabilities = ["create", "read", "update", "delete", "list", "sudo"] } # Deny access to secret/admin path "secret/data/admin" { capabilities = ["deny"] } path "secret/data/admin/*" { capabilities = ["deny"] } # Deny list access to secret/admin path "secret/metadata/admin" { capabilities = ["deny"] } path "secret/metadata/admin/*" { capabilities = ["deny"] }

5. Klicken Sie auf Richtlinie erstellen.

Secrets erstellen

Nachdem Sie die verschiedenen Richtlinien erstellt haben, können Sie nun Secrets anlegen.

1. Kehren Sie zu Cloud Shell zurück und führen Sie die folgenden Befehle aus, um mehrere Secrets im Pfad secret/security zu erstellen:

vault kv put secret/security/first username=password vault kv put secret/security/second username=password

2. Erstellen Sie mehrere Secrets im Pfad secret/appdev:

vault kv put secret/appdev/first username=password vault kv put secret/appdev/beta-app/second username=password

3. Erstellen Sie mehrere Secrets im Pfad secret/admin:

vault kv put secret/admin/first admin=password vault kv put secret/admin/supersecret/second admin=password

Sicherheit für die Anwendungsentwicklung überprüfen

Nachdem Sie mehrere Secrets erstellt haben, überprüfen wir nun, ob diese Richtlinien durchgesetzt werden. Melden Sie sich zuerst als appdev-Nutzerin oder -Nutzer an und prüfen Sie, worauf Sie Zugriff haben.

1. Führen Sie den folgenden Befehl aus, um sich als appdev-Nutzerin oder -Nutzer anzumelden:

vault login -method="userpass" username="app-dev" password="appdev123"

2. Versuchen Sie nun, das Secret appdev/first abzurufen:

vault kv get secret/appdev/first

Es sollte folgende Ausgabe angezeigt werden:

======= Metadata ======= Key Value --- ----- created_time 2022-01-12T18:58:13.18635501Z custom_metadata <nil> deletion_time n/a destroyed false version 1 ====== Data ====== Key Value --- ----- username password

3. Rufen Sie das Secret unter secret/appdev/beta-app/second ab:

vault kv get secret/appdev/beta-app/second

Es sollte folgende Ausgabe angezeigt werden:

======= Metadata ======= Key Value --- ----- created_time 2022-01-12T18:58:13.829274247Z custom_metadata <nil> deletion_time n/a destroyed false version 1 ====== Data ====== Key Value --- ----- username password

4. Erstellen Sie ein neues Secret:

vault kv put secret/appdev/appcreds credentials=creds123

5. Löschen Sie das Secret:

vault kv destroy -versions=1 secret/appdev/appcreds

6. Versuchen Sie, ein Secret aus secret/security abzurufen:

vault kv get secret/security/first

Es sollte die folgende Fehlermeldung angezeigt werden:

Error reading secret/data/security/first: Error making API request. URL: GET http://127.0.0.1:8200/v1/secret/data/security/first Code: 403. Errors: * 1 error occurred: * permission denied

7. Versuchen Sie, alle Secrets unter secret/ aufzulisten:

vault kv list secret/

Es sollte wieder eine Fehlermeldung angezeigt werden:

Error listing secret/metadata: Error making API request. URL: GET http://127.0.0.1:8200/v1/secret/metadata?list=true Code: 403. Errors: * 1 error occurred: * permission denied

Sehr gut. Sie haben Secrets im Pfad secret/appdev abgerufen und erstellt und überprüft, ob Sie auf Secrets außerhalb dieses Pfads zugreifen können.

„security“-Richtlinie prüfen

1. Führen Sie den folgenden Befehl aus, um sich als security-Nutzerin oder -Nutzer anzumelden:

vault login -method="userpass" username="security" password="security123"

2. Versuchen Sie nun, das Secret security/first abzurufen:

vault kv get secret/security/first

Es sollte folgende Ausgabe angezeigt werden:

======= Metadata ======= Key Value --- ----- created_time 2022-01-12T18:58:04.299036073Z custom_metadata <nil> deletion_time n/a destroyed false version 1 ====== Data ====== Key Value --- ----- username password

3. Rufen Sie das Secret unter secret/security/second ab:

vault kv get secret/security/second

Es sollte folgende Ausgabe angezeigt werden:

======= Metadata ======= Key Value --- ----- created_time 2022-01-12T18:58:13.829274247Z custom_metadata <nil> deletion_time n/a destroyed false version 1 ====== Data ====== Key Value --- ----- username password

4. Erstellen Sie ein neues Secret in secret/security/supersecure:

vault kv put secret/security/supersecure/bigsecret secret=idk

5. Löschen Sie das Secret:

vault kv destroy -versions=1 secret/security/supersecure/bigsecret

6. Versuchen Sie, ein Secret aus secret/appdev zu lesen:

vault kv get secret/appdev/first

Es sollte die folgende Ausgabe angezeigt werden:

======= Metadata ======= Key Value --- ----- created_time 2022-01-12T18:58:13.18635501Z custom_metadata <nil> deletion_time n/a destroyed false version 1 ====== Data ====== Key Value --- ----- username password

7. Versuchen Sie, alle Secrets unter secret/ aufzulisten:

vault kv list secret/

Es sollte die folgende Ausgabe angezeigt werden:

Keys ---- admin/ appdev/ security/

8. Aktivieren Sie eine neue Secrets Engine:

vault secrets enable -path=supersecret kv Success! Enabled the kv secrets engine at: supersecret/

9. Versuchen Sie, das Secret secret/admin/first aufzurufen:

vault kv get secret/admin/first

Es sollte die folgende Fehlermeldung angezeigt werden:

Error reading secret/data/admin/first: Error making API request. URL: GET http://127.0.0.1:8200/v1/secret/data/admin/first Code: 403. Errors: * 1 error occurred: * permission denied

10. Versuchen Sie, die Secrets unter secret/admin aufzulisten:

vault kv list secret/admin

Auch in diesem Fall sollte eine Fehlermeldung angezeigt werden:

Error listing secret/metadata/admin: Error making API request. URL: GET http://127.0.0.1:8200/v1/secret/metadata/admin?list=true Code: 403. Errors: * 1 error occurred: * permission denied

Sehr gut. Sie haben Secrets im Pfad secret/ abgerufen und erstellt sowie eine Secrets Engine aktiviert. Außerdem wurde Ihnen der Zugriff auf den Pfad secret/admin verweigert, wie in der Richtlinie festgelegt.

Richtlinie für Admins prüfen

1. Führen Sie den folgenden Befehl aus, um sich als admin-Nutzerin oder -Nutzer anzumelden:

vault login -method="userpass" username="admin" password="admin123"

2. Versuchen Sie nun, das Secret admin/first abzurufen:

vault kv get secret/admin/first

Es sollte folgende Ausgabe angezeigt werden:

======= Metadata ======= Key Value --- ----- created_time 2022-01-12T18:58:18.521925218Z custom_metadata <nil> deletion_time n/a destroyed false version 1 ==== Data ==== Key Value --- ----- admin password

3. Rufen Sie ein Secret unter secret/security/first ab:

vault kv get secret/security/first

Es sollte folgende Ausgabe angezeigt werden:

======= Metadata ======= Key Value --- ----- created_time 2022-01-12T18:58:04.299036073Z custom_metadata <nil> deletion_time n/a destroyed false version 1 ====== Data ====== Key Value --- ----- username password

4. Erstellen Sie ein neues Secret:

vault kv put secret/webserver/credentials web=awesome

5. Löschen Sie das Secret:

vault kv destroy -versions=1 secret/webserver/credentials

6. Versuchen Sie, Secrets aus secret/appdev abzurufen:

vault kv get secret/appdev/first

Es sollte die folgende Ausgabe angezeigt werden:

======= Metadata ======= Key Value --- ----- created_time 2022-01-12T18:58:13.18635501Z custom_metadata <nil> deletion_time n/a destroyed false version 1 ====== Data ====== Key Value --- ----- username password

7. Versuchen Sie, alle Secrets unter secret/appdev aufzulisten:

vault kv list secret/appdev/

Es sollte die folgende Ausgabe angezeigt werden:

Keys ---- appcreds beta-app/ first

8. Listen Sie alle Richtlinien auf:

vault policy list

Es sollte die folgende Ausgabe angezeigt werden:

admin appdev default default-ceiling demo-policy security root

9. Führen Sie den folgenden Befehl aus, um die Werte der Richtlinien in eine Textdatei zu kopieren und in den Cloud Storage-Bucket hochzuladen:

vault policy list > policies-update.txt gcloud storage cp policies-update.txt gs://$PROJECT_ID

10. Aktivieren Sie die Authentifizierungsmethode gcp:

vault auth enable gcp

11. Listen Sie abschließend die aktivierten Authentifizierungsmethoden auf:

vault auth list Path Type Accessor Description ---- ---- -------- ----------- gcp/ gcp auth_gcp_faa3d15f n/a token/ token auth_token_066c5ebd token based credentials userpass/ userpass auth_userpass_929fe9bd n/a

Sie haben überprüft, dass Sie die Administratorberechtigungen für die von Ihnen erstellte Richtlinie haben.

Klicken Sie auf Fortschritt prüfen. Richtlinien für Secrets

Pfade

Wie Sie möglicherweise bereits im Richtliniencode für die Nutzerin bzw. den Nutzer mit der Rolle security gesehen haben, wurden einige neue Elemente eingeführt: data/ und metadata/.

Der Pfadendpunkt metadata/ gibt eine Liste von Schlüsselnamen am angegebenen Speicherort zurück. Darüber hinaus sind mit diesem Befehl die Werte selbst nicht zugänglich. Für das Schreiben und Lesen von Versionen gilt das Präfix data/. Für das Auflisten, Lesen und Löschen gilt Folgendes:

• Versionen schreiben und lesen – data/
• Schlüssel auflisten – metadata/
• Versionen lesen – metadata/
• Versionen des Secret löschen – destroy/
• Alle Metadatenversionen für einen Schlüssel löschen – metadata/

Wenn Sie beispielsweise den Zugriff auf ein Secret unter secret/example unterbinden möchten, müssen Sie die folgende Eingabe mit data/ verwenden:

path "secret/data/example" { capabilities = ["deny"] }

Wenn Sie den Zugriff auf die Liste secret/examples unterbinden möchten, müssen Sie die folgende Eingabe mit metadata/ verwenden:

path "secret/metadata/examples/*" { capabilities = ["deny"] }

Aufgabe 8: Detailgenaue Steuerung

Zusätzlich zu den Standardfunktionen bietet Vault eine detailgenaue Kontrolle über die Berechtigungen für einen bestimmten Pfad. Die mit einem Pfad verknüpften Funktionen haben dabei Vorrang vor den Berechtigungen für Parameter.

Parameterbeschränkungen

In Vault werden Daten als key=value-Paare dargestellt. Vault-Richtlinien können optional Pfade basierend auf den Schlüsseln und Daten für diese Schlüssel weiter einschränken, wenn die Berechtigungen für einen Pfad ausgewertet werden. Es sind folgende Optionen für eine detailgenaue Steuerung verfügbar:

• required_parameters: Eine Liste der Parameter, die angegeben werden müssen.
• allowed_parameters: Eine Liste der Schlüssel und Werte, die im angegebenen Pfad zulässig sind.
• denied_parameters: Eine Liste der Parameter und Werte, die gesperrt sind. Die hier angegebenen Werte haben Vorrang vor allowed_parameters.

Weitere Informationen zur detailgenauen Steuerung finden Sie in der Dokumentation zur detailgenauen Steuerung.

Das wars! Sie haben das Lab erfolgreich abgeschlossen.

Wie Sie gesehen haben, spielen Richtlinien in Vault eine wichtige Rolle. Auch wenn es sich mit dem Root-Token am einfachsten starten lässt, sollten Sie den Zugriff auf Vault möglichst schnell einschränken. Dafür steht das Richtliniensystem zur Verfügung.

Richtlinien sind einfach aufgebaut und anwendbar. Da alle Authentifizierungsmethoden dem zentralen Richtliniensystem zugeordnet sein müssen, müssen Sie nur über dieses Richtliniensystem Bescheid wissen.

In diesem Lab haben Sie Richtlinien erstellt und verwaltet, sie mit Nutzerinnen bzw. Nutzern und Tokens verknüpft und deren Berechtigungen überprüft.

Weitere Informationen

Weitere Informationen zu Vault finden Sie hier:

• Anleitungen für den Einstieg in Vault
• Vault-Dokumentation
• Vault-Richtliniendokumentation
• Anleitung zu Vault-Richtlinien

Google Cloud-Schulungen und -Zertifizierungen

In unseren Schulungen erfahren Sie alles zum optimalen Einsatz unserer Google Cloud-Technologien und können sich entsprechend zertifizieren lassen. Unsere Kurse vermitteln technische Fähigkeiten und Best Practices, damit Sie möglichst schnell mit Google Cloud loslegen und Ihr Wissen fortlaufend erweitern können. Wir bieten On-Demand-, Präsenz- und virtuelle Schulungen für Anfänger wie Fortgeschrittene an, die Sie individuell in Ihrem eigenen Zeitplan absolvieren können. Mit unseren Zertifizierungen weisen Sie nach, dass Sie Experte im Bereich Google Cloud-Technologien sind.

Anleitung zuletzt am 4. Juni 2026 aktualisiert

Lab zuletzt am 4. Juni 2026 getestet

© 2026 Google LLC. Alle Rechte vorbehalten. Google und das Google-Logo sind Marken von Google LLC. Alle anderen Unternehmens- und Produktnamen können Marken der jeweils mit ihnen verbundenen Unternehmen sein.