ExamsLabs Vault-Associate Prüfungsfragen Real Vault-Associate Practice Dumps [Q32-Q52]

Der Befehl, der die Sicherheitsanforderung, dass Geheimnisse nicht in der Shell-Historie erscheinen dürfen, nicht erfüllt, ist B. vault kv put secret/password value-itsasecret. Mit diesem Befehl wird der geheime Wert "itsasecret" in der Key/Value Secrets Engine unter dem Pfad secret/password gespeichert, aber der geheime Wert wird auch in der Shell-Historie angezeigt, auf die andere Benutzer oder böswillige Akteure zugreifen können. Dies ist keine sichere Art, Geheimnisse im Vault zu speichern.
Die anderen Befehle sind sicherere Methoden, um Geheimnisse in Vault zu speichern, ohne sie in der Shell-Historie preiszugeben.
A). generate-password | vault kv put secret/password value würde eine Pipe verwenden, um die Ausgabe des generate-password-Befehls, bei dem es sich um ein Skript oder ein Tool handeln könnte, das ein Zufallspasswort generiert, an den vault kv put-Befehl weiterzuleiten, der das Passwort in der Key/Value-Secrets-Engine unter dem Pfad secret/password speichern würde. Das Passwort wäre in der Shell-Historie nicht sichtbar, nur die Befehle.
C). vault kv put secret/password [email protected] würde die @-Syntax verwenden, um den geheimen Wert aus einer Datei namens data.txt zu lesen, die verschlüsselt oder durch Dateiberechtigungen geschützt sein könnte, und ihn in der Key/Value Secrets Engine unter dem Pfad secret/password speichern. Der Dateiname wäre in der Shell-Historie sichtbar, nicht aber der geheime Wert.
D). vault kv put secret/password value-SSECRET_VALUE würde die Syntax -S verwenden, um den geheimen Wert aus der Umgebungsvariablen SECRET_VALUE zu lesen, die in der Shell-Sitzung gesetzt und aufgehoben werden kann, und ihn in der Key/Value Secrets Engine unter dem Pfad secret/password speichern. Der Name der Umgebungsvariablen wäre in der Shell-Historie sichtbar, nicht aber der geheime Wert.
Referenz:
[Write Secrets | Vault | HashiCorp Developer]

Dynamische Geheimnisse werden bei Bedarf von Vault generiert und haben eine begrenzte Lebensdauer (Time-to-Live, TTL). Sie gewährleisten nicht, dass Administratoren jedes verwendete Passwort sehen können, da sie oft verschlüsselt und flüchtig sind. Die Vorteile von dynamischen Geheimnissen sind:
Sie unterstützen Systeme, die von Haus aus keine Methode zum Ablaufen von Anmeldeinformationen bieten, wie Datenbanken, Cloud-Anbieter, SSH usw. Vault kann die Anmeldeinformationen widerrufen, wenn sie nicht mehr benötigt werden oder wenn der Lease abläuft.
Sie minimieren den Schaden, der durch den Verlust von Zugangsdaten entsteht, da sie kurzlebig sind und leicht ausgetauscht oder widerrufen werden können. Wenn eine Zugangsberechtigung kompromittiert wird, hat der Angreifer nur ein begrenztes Zeitfenster, um sie zu verwenden, bevor sie ungültig wird.
Sie ersetzen umständliche Tools und Praktiken zur Passwortrotation, da Vault die Generierung und den Widerruf von Zugangsdaten automatisch und sicher abwickeln kann. Dies reduziert den betrieblichen Aufwand und die Komplexität der Verwaltung von Geheimnissen.

In Vault gibt es die folgenden drei Richtlinien:
Admins: Diese Richtlinie gewährt vollen Zugriff auf alle Geheimnisse und Vorgänge in Vault. Sie kann von Administratoren oder Operatoren verwendet werden, die alle Aspekte von Vault verwalten müssen.
Standard: Diese Richtlinie gewährt Zugriff auf alle Geheimnisse und Operationen in Vault, mit Ausnahme derer, die spezielle Richtlinien erfordern. Sie kann als Ausweichrichtlinie verwendet werden, wenn keine andere Richtlinie passt.
Transit: Diese Richtlinie gewährt nur Zugriff auf die Transitgeheimnis-Engine, die kryptografische Funktionen für Daten während des Transports durchführt. Sie kann von Anwendungen oder Diensten verwendet werden, die Daten mit Vault verschlüsseln oder entschlüsseln müssen.
Diese Richtlinien ermöglichen es einer Organisation, nützliche Aufgaben auszuführen, wie z. B.:
Verschlüsseln, Entschlüsseln und Wiederverschlüsseln von Daten mit der Transit-Engine in einer einzigen Richtlinie: Diese Richtlinie gewährt Zugriff sowohl auf die Transitgeheimnis-Engine als auch auf die Standardrichtlinie, die es ermöglicht, jeden beliebigen Vorgang mit jedem Geheimnis in Vault durchzuführen.
Erstellen eines Transitverschlüsselungsschlüssels zum Verschlüsseln, Entschlüsseln und Wiederverschlüsseln von verschlüsselten Daten: Diese Richtlinie gewährt nur Zugriff auf die Transitgeheimnis-Engine und die zugehörigen Schlüssel, die für die Ver- und Entschlüsselung von Daten bei der Übertragung mit AES-GCM mit einem 256-Bit-AES-Schlüssel oder anderen unterstützten Schlüsseltypen verwendet werden.
Getrennte Berechtigungen für Aktionen im Zusammenhang mit der Transitgeheimnis-Engine: Diese Richtlinie gewährt nur Zugriff auf bestimmte Aktionen im Zusammenhang mit der Transitgeheimnis-Engine, z. B. das Erstellen von Schlüsseln oder das Verarbeiten von Anfragen. Sie gewährt keinen Zugriff auf andere Vorgänge oder Geheimnisse in Vault.

Eine Identitätsgruppe ist eine Sammlung von Einheiten, die einige gemeinsame Attribute aufweisen. Einer Identitätsgruppe können eine oder mehrere Richtlinien zugeordnet sein, die an alle Mitglieder der Gruppe vererbt werden. Eine Identitätsgruppe kann auch Untergruppen haben, die die Richtlinien und Attribute für eine Teilmenge von Entitäten weiter verfeinern können.
Einer der Anwendungsfälle für eine Identitätsgruppe ist die konsistente Anwendung desselben Satzes von Richtlinien auf eine Sammlung von Einheiten. Ein Unternehmen kann zum Beispiel verschiedene Teams oder Abteilungen haben, wie z. B. Technik, Vertrieb oder Marketing. Jedes Team kann seine eigene Identitätsgruppe haben, mit Richtlinien, die den Zugriff auf die Geheimnisse und Ressourcen gewähren, die für ihre Arbeit relevant sind. Durch die Erstellung einer Identitätsgruppe für jedes Team kann das Unternehmen sicherstellen, dass die Personen, die zu den einzelnen Teams gehören, über die gleichen Zugriffsrechte und Berechtigungen verfügen, unabhängig davon, welche Authentifizierungsmethode sie für die Anmeldung bei Vault verwenden. Referenz: Identität: Entitäten und Gruppen | Vault | HashiCorp Developer, vault_identity_group | Ressourcen | hashicorp/vault | Terraform | Terraform Registry

Integrated Storage ist ein Raft-basiertes Speicher-Backend, das es Vault ermöglicht, seine Daten intern zu speichern, ohne auf ein externes Speichersystem angewiesen zu sein. Außerdem kann Vault damit im Hochverfügbarkeitsmodus mit automatischer Leader-Wahl und Failover betrieben werden. Der integrierte Speicher ist jedoch nicht immun gegen Datenverlust oder -beschädigung aufgrund von Hardwareausfällen, Netzwerkpartitionen oder menschlichen Fehlern. Es wird daher empfohlen, die Snapshot-Funktion zu verwenden, um die Vault-Daten regelmäßig oder bei Bedarf zu sichern und wiederherzustellen. Ein Snapshot ist eine zeitpunktbezogene Erfassung der gesamten Vault-Daten, einschließlich der verschlüsselten Geheimnisse, der Konfiguration und der Metadaten. Snapshots können mit dem Befehl vault operator raft snapshot oder dem API-Endpunkt sys/storage/raft/snapshot erstellt und wiederhergestellt werden. Snapshots sind verschlüsselt und können nur mit einem Quorum von Entsiegelungs- oder Wiederherstellungsschlüsseln wiederhergestellt werden. Snapshots sind außerdem portabel und können für die Migration von Daten zwischen verschiedenen Vault-Clustern oder Speicher-Backends verwendet werden. Referenz: https://developer.hashicorp.com/vault/docs/concepts/integrated-storage1, https://developer.hashicorp.com/vault/docs/commands/operator/raft/snapshot2, https://developer.hashicorp.com/vault/api-docs/system/storage/raft/snapshot3

Die Aussage ist wahr. Wenn eine Authentifizierungsmethode deaktiviert wird, verlieren alle über diese Methode authentifizierten Benutzer den Zugang. Das liegt daran, dass die von der Authentifizierungsmethode ausgestellten Token automatisch widerrufen werden, wenn die Authentifizierungsmethode deaktiviert wird. Dies verhindert, dass die Benutzer mit den widerrufenen Token irgendwelche Operationen in Vault durchführen können. Um wieder Zugriff zu erhalten, müssen sich die Benutzer erneut mit einer anderen Authentifizierungsmethode authentifizieren, die aktiviert und mit den entsprechenden Richtlinien versehen ist. Referenz: Authentifizierungsmethoden | Vault | HashiCorp Developer, auth disable - Befehl | Vault | HashiCorp Developer

Die geheime Vault-Engine, die zum Aufbau Ihrer eigenen internen Zertifizierungsstelle verwendet werden kann, ist die PKI-Geheim-Engine. Die PKI-Secret-Engine generiert dynamische X.509-Zertifikate nach Bedarf, ohne dass manuelle Prozesse wie das Generieren von privaten Schlüsseln und CSRs, das Einreichen bei einer CA und das Warten auf die Überprüfung und Signierung erforderlich sind. Die PKI-Geheimdienst-Engine kann als Stammzertifizierungsstelle oder Zwischenzertifizierungsstelle fungieren und Zertifikate für verschiedene Zwecke ausstellen, z. B. TLS, Code Signing, E-Mail-Verschlüsselung usw. Die PKI-Secret-Engine kann auch den Lebenszyklus von Zertifikaten verwalten, z. B. Rotation, Widerruf, Erneuerung und CRL-Erstellung. Die PKI Secret Engine kann auch mit externen Zertifizierungsstellen wie Venafi oder Entrust integriert werden, um die Ausstellung und Verwaltung von Zertifikaten zu delegieren. Referenz: PKI - Secrets Engines | Vault | HashiCorp Developer, Build Your Own Certificate Authority (CA) | Vault - HashiCorp Learn

Der Fehler wurde ausgelöst, weil der Richtliniencode eine ungültige Fähigkeit, nämlich "write", enthält. Die gültigen Fähigkeiten für eine Richtlinie sind "create", "read", "update", "delete", "list" und "sudo". Die Fähigkeit "write" wird von Vault nicht erkannt und sollte durch "create" ersetzt werden, mit der neue Geheimnisse erstellt oder bestehende überschrieben werden können. Die anderen Aussagen sind nicht korrekt, da der Platzhalter (*) und die sudo-Fähigkeit beide in einer Richtlinie gültig sind. Der Platzhalter passt auf eine beliebige Anzahl von Zeichen innerhalb eines Pfadsegments, und die sudo-Fähigkeit erlaubt die Durchführung bestimmter Operationen, die Root-Rechte erfordern.
Referenz:
[Policy Syntax | Vault | HashiCorp Developer]
[Policy Syntax | Vault | HashiCorp Developer]

Die payload.json-Datei mit dem richtigen Inhalt ist C. Diese Datei enthält ein JSON-Objekt mit einem einzigen Schlüssel, "plaintext", und einem Wert, der die base64-kodierte Zeichenfolge der zu verschlüsselnden Daten ist. Dies ist das Format, das die Vault-API für den Transitverschlüsselungsendpunkt erwartet1. Die anderen Dateien sind nicht korrekt, weil sie entweder den falschen Schlüsselnamen, das falsche Wertformat oder die falsche JSON-Syntax haben.
Referenz:
Daten verschlüsseln - Transit Secrets Engine | Vault | HashiCorp Developer

Dieser Screenshot wird angezeigt, wenn Sie Authentifizierungsmethoden in der GUI aktivieren. Authentifizierungsmethoden sind die Methoden, mit denen sich Benutzer und Anwendungen bei Vault authentifizieren. Vault unterstützt viele verschiedene Authentifizierungsmethoden, einschließlich Benutzername und Passwort, GitHub und mehr. Sie können eine oder mehrere Authentifizierungsmethoden aus dem Raster der Optionen aktivieren, die in drei Kategorien unterteilt sind: Allgemein, Cloud und Infra. Jede Option hat einen Namen, eine Beschreibung und ein Logo. Sie können Authentifizierungsmethoden auch über die Vault CLI oder API aktivieren.
Das Aktivieren von Richtlinien, Authentifizierungs-Engines und Secret-Engines ist eine andere Aufgabe, die mit diesem Screenshot nichts zu tun hat. Richtlinien sind Regeln, die den Zugriff auf Vault-Ressourcen regeln, z. B. Geheimnisse, Authentifizierungsmethoden und Prüfgeräte. Authentifizierungs-Engines sind Komponenten von Vault, die die Authentifizierung durchführen und den authentifizierten Entitäten Richtlinien zuweisen. Secret Engines sind Komponenten von Vault, die Daten speichern, erzeugen oder verschlüsseln. Diese Aufgaben haben andere GUI-Seiten und Optionen als im Screenshot.
Referenz:
[Authentifizierung | Tresor | HashiCorp Entwickler]
[Richtlinien | Tresor | HashiCorp Entwickler]
[Authentifizierung | Tresor | HashiCorp Entwickler]
[Secrets Engines | Vault | HashiCorp Developer]

Vault Agent ist ein Client-Daemon, der die folgenden Funktionen bietet:
Auto-Auth - Automatische Authentifizierung bei Vault und Verwaltung des Token-Erneuerungsprozesses für lokal abgerufene dynamische Geheimnisse.
API Proxy - Ermöglicht es Vault Agent, als Proxy für die API von Vault zu fungieren und dabei optional das Auto-Auth-Token zu verwenden (oder die Verwendung zu erzwingen).
Zwischenspeicherung - Ermöglicht die clientseitige Zwischenspeicherung von Antworten mit neu erstellten Token und Antworten mit geleasten Geheimnissen, die auf der Grundlage dieser neu erstellten Token generiert wurden. Der Agent verwaltet auch die Erneuerung der zwischengespeicherten Token und Leases.
Templating - Ermöglicht das Rendern von benutzerdefinierten Templates durch den Vault Agent unter Verwendung des Tokens, das durch den Auto-Auth-Schritt generiert wurde.
Prozessüberwachungsmodus - Führt einen untergeordneten Prozess mit als Umgebungsvariablen eingefügten Vault-Geheimnissen aus.
Einer der Vorteile der Verwendung des Vault-Agenten ist, dass er den Lebenszyklus von zwischengespeicherten Token und Leases automatisch verwaltet. Das bedeutet, dass der Agent die Logik für die Erneuerung und den Entzug von Token sowie die Logik für die Erneuerung und den Entzug von Leases für die vom Agenten zwischengespeicherten Geheimnisse übernimmt. Dadurch wird der Aufwand für die Anwendungsentwickler und -betreiber verringert und sichergestellt, dass die Token und Geheimnisse immer gültig und aktuell sind. Referenz: Vault Agent | Vault | HashiCorp Developer, Caching - Vault Agent | Vault | HashiCorp Developer

Die Konfiguration des Vault-Siegels kann auf zwei Arten festgelegt werden: über die Vault-Konfigurationsdatei oder über Umgebungsvariablen. Die Vault-Konfigurationsdatei ist eine Textdatei, die die Einstellungen und Optionen für Vault enthält, z. B. das Speicher-Backend, den Listener, die Telemetrie und das Seal. Die Seal-Stanza in der Konfigurationsdatei gibt den Siegel-Typ und die Parameter an, die für den zusätzlichen Datenschutz verwendet werden sollen, z. B. die Verwendung von HSM- oder Cloud-KMS-Lösungen zum Ver- und Entschlüsseln des Root-Schlüssels. Die Siegelkonfiguration kann auch über Umgebungsvariablen festgelegt werden, die Vorrang vor den Werten in der Konfigurationsdatei haben. Den Umgebungsvariablen wird das Präfix VAULT_SEAL_ vorangestellt, gefolgt von der Siegelart und dem Parameternamen. VAULT_SEAL_AWSKMS_REGION legt zum Beispiel die Region für das AWS KMS-Siegel fest. Referenz: Siegel - Konfiguration | Vault | HashiCorp Developer, Umgebungsvariablen | Vault | HashiCorp Developer

Wenn Sie sich die Details des Vault-Tokens ansehen, hilft Ihnen der Richtlinienschlüssel, die Pfade zu finden, auf die das Token zugreifen kann. Richtlinien sind ein deklarativer Weg, um den Zugriff auf bestimmte Pfade und Operationen in Vault zu erlauben oder zu verbieten. Richtlinien werden in HCL oder JSON geschrieben und sind Token durch ihren Namen zugeordnet. Richtlinien sind standardmäßig verweigert, so dass eine leere Richtlinie keine Berechtigung im System gewährt. Einem Token können eine oder mehrere Richtlinien zugeordnet sein, und die effektive Richtlinie ist die Vereinigung aller einzelnen Richtlinien. Sie können die Token-Details mit dem Befehl vault token lookup oder dem API-Endpunkt auth/token/lookup anzeigen. Die Ausgabe zeigt den Richtlinienschlüssel mit einer Liste der Richtliniennamen, die mit dem Token verknüpft sind. Sie können den Inhalt einer Richtlinie auch mit dem Befehl vault policy read oder mit dem API-Endpunkt sys/policy einsehen. In der Ausgabe wird der Regelschlüssel mit der HCL- oder JSON-Darstellung der Richtlinie angezeigt. Die Regeln geben die Pfade und die Funktionen (wie Erstellen, Lesen, Aktualisieren, Löschen, Auflisten usw.) an, die die Richtlinie erlaubt oder verweigert. Referenz: https://developer.hashicorp.com/vault/docs/concepts/policies4, https://developer.hashicorp.com/vault/docs/commands/token/lookup5, https://developer.hashicorp.com/vault/api-docs/auth/token#lookup-a-token6, https://developer.hashicorp.com/vault/docs/commands/policy/read7, https://developer.hashicorp.com/vault/api-docs/system/policy8

Batch-Tokens sind eine Art von Token, die nicht im Backend von Vault gespeichert werden, sondern verschlüsselte Blobs sind, die genügend Informationen enthalten, um Vault-Aktionen durchzuführen. Batch-Tokens sind extrem leichtgewichtig und skalierbar und können den Durchsatz bei der Token-Erstellung verbessern. Batch-Tokens eignen sich für hochvolumige und kurzlebige Workloads wie Container oder serverlose Funktionen, die kurzlebige und nicht erneuerbare Tokens erfordern. Batch-Tokens können mit dem Flag -type=batch im Befehl vault token create oder durch Konfigurieren des Parameters token_type in den Rollen- oder Mount-Optionen der Auth-Methode erstellt werden. Batch-Tokens haben im Vergleich zu Service-Tokens einige Einschränkungen, wie das Fehlen von Erneuerungs-, Widerrufs-, Auflistungs-, Accessor- und Cubbyhole-Funktionen. Daher sollten Batch-Tokens nur mit Vorsicht und nur dann verwendet werden, wenn die Kompromisse akzeptabel sind. Referenz: https://developer.hashicorp.com/vault/tutorials/tokens/batch-tokens1, https://developer.hashicorp.com/vault/docs/commands/token/create2, https://developer.hashicorp.com/vault/docs/concepts/tokens#token-types3

Die Umgebungsvariable VAULT_ADDR überschreibt die Standard-Vault-Serveradresse der CLI. Die Umgebungsvariable VAULT_ADDR gibt die Adresse des Vault-Servers an, die für die Kommunikation mit Vault von anderen Anwendungen oder Prozessen verwendet wird. Wenn Sie diese Variable setzen, müssen Sie die Adresse des Vault-Servers nicht fest in Ihrem Code oder Ihren Konfigurationsdateien kodieren, und Sie können auch verschiedene Adressen für unterschiedliche Umgebungen oder Szenarien verwenden. So können Sie beispielsweise einen lokalen Entwicklungsserver für Testzwecke und einen Produktionsserver für die Bereitstellung Ihrer Anwendung verwenden. Referenz: Befehle (CLI) | Vault | HashiCorp Developer, Vault Agent - Geheimnisse als Umgebungsvariablen | Vault | HashiCorp Developer

Der Befehl zur Erneuerung des Tresor-Leasings erhöht die Lease-Zeit ab dem aktuellen Zeitpunkt, nicht ab dem Ende des Leasings. Das bedeutet, dass der Benutzer eine bestimmte Zeitspanne anfordern kann, die er für den Lease verbleiben lassen möchte, das so genannte Inkrement. Dabei handelt es sich nicht um ein Inkrement am Ende der aktuellen TTL, sondern um ein Inkrement ab dem aktuellen Zeitpunkt. Zum Beispiel würde vault lease renew -increment=3600 my-lease-id verlangen, dass die TTL des Leases auf 1 Stunde (3600 Sekunden) ab jetzt angepasst wird. Dadurch, dass das Inkrement zum aktuellen Zeitpunkt und nicht zum Ende der Lease gesetzt wird, können Benutzer die Länge der Leases verringern, wenn sie die Zugangsdaten nicht für die gesamte mögliche Lease-Periode benötigen, so dass diese Zugangsdaten früher ablaufen und die Ressourcen früher bereinigt werden können. Das angeforderte Inkrement ist völlig unverbindlich. Das Backend, das für das Geheimnis zuständig ist, kann es komplett ignorieren1. Referenz:
Mieten, Erneuern und Widerrufen | Vault | HashiCorp Developer

Vault-Richtlinien werden im HCL- oder JSON-Format geschrieben und sind Token oder Rollen namentlich zugeordnet. Richtlinien definieren die Berechtigungen und Einschränkungen für den Zugriff auf und die Durchführung von Operationen mit bestimmten Pfaden und Geheimnissen in Vault. Richtlinien sind standardmäßig verweigert, was bedeutet, dass eine leere Richtlinie keine Berechtigung im System gewährt und jede Anfrage, die nicht explizit durch eine Richtlinie erlaubt ist, implizit verweigert wird1. Einige der Funktionen und Vorteile von Vault-Richtlinien sind:
Richtlinien sind pfadbasiert, d. h. sie gleichen den Anfragepfad mit einer Reihe von Regeln ab, die die erlaubten oder verweigerten Fähigkeiten angeben, wie z. B. Erstellen, Lesen, Aktualisieren, Löschen, Liste, sudo usw.2.
Richtlinien sind additiv, d. h., wenn einem Token oder einer Rolle mehrere Richtlinien zugeordnet sind, ist die effektive Richtlinie die Vereinigung aller einzelnen Richtlinien. Im Falle eines Konflikts wird die erlaubteste Fähigkeit gewährt3.
Richtlinien können globale Muster wie * und + verwenden, um mehrere Pfade oder Segmente mit einer einzigen Regel abzugleichen. Beispielsweise passt der Pfad "secret/*" auf jeden Pfad, der mit secret/ beginnt, und der Pfad "secret/+/config" passt auf jeden Pfad mit zwei Segmenten nach secret/ und endend mit config4.
Richtlinien können Schablonen verwenden, um bestimmte Werte in die Regeln einzubauen, z. B. Identitätsinformationen, Zeit, Zufälligkeit usw. Der Pfad "secret/{{identity.entity.id}}/*" beispielsweise entspricht jedem Pfad, der mit secret/ beginnt, gefolgt von der Entity-ID des Antragstellers5.
Richtlinien können mit den Vault-Richtlinienbefehlen oder den sys/policy-API-Endpunkten verwaltet werden. Über diese Schnittstellen können Sie Richtlinien schreiben, lesen, auflisten und löschen6.
Die Standardrichtlinie ist eine integrierte Richtlinie, die standardmäßig an alle Token angehängt ist und nicht gelöscht werden kann. Die Standardrichtlinie kann jedoch mit dem Befehl vault policy write oder dem API-Endpunkt sys/policy geändert werden. Die Standardrichtlinie bietet allgemeine Berechtigungen für Token, wie z. B. sich selbst zu erneuern, ihre eigenen Informationen nachzuschlagen, Token zum Einpacken von Antworten zu erstellen und zu verwalten, usw.7.
Sie müssen nicht unbedingt YAML verwenden, um Richtlinien zu definieren, da Vault sowohl das HCL- als auch das JSON-Format unterstützt. HCL ist eine menschenfreundliche Konfigurationssprache, die auch JSON-kompatibel ist, was bedeutet, dass JSON auch als gültige Eingabe für Richtlinien verwendet werden kann8.
Vault muss nicht neu gestartet werden, damit eine Richtlinienänderung wirksam wird, da die Richtlinien im Speicher gespeichert und ausgewertet werden. Jede Änderung einer Richtlinie wird sofort im System reflektiert, und alle Token oder Rollen, denen diese Richtlinie zugeordnet ist, sind von der Änderung betroffen.

Vault unterstützt CIDR-gebundene Token, d. h. Token, die nur von einer bestimmten Gruppe von IP-Adressen oder Netzwerkbereichen aus verwendet werden können. Dies ist eine Möglichkeit, den Umfang und die Exposition eines Tokens einzuschränken, falls es kompromittiert oder durchgesickert ist. CIDR-gebundene Token können durch Angabe des Parameters bound_cidr_list beim Erstellen oder Aktualisieren einer Token-Rolle oder durch Verwendung der Option -bound-cidr beim Erstellen eines Tokens mit dem Befehl vault token create erstellt werden. CIDR-gebundene Token können auch von einigen Authentifizierungsmethoden wie AWS oder Kubernetes erstellt werden, die die Token automatisch an die Quell-IP oder das Netzwerk des Clients binden können. Referenz: Token - Auth Methods | Vault | HashiCorp Developer, vault token create - Command | Vault | HashiCorp Developer

Die Google Cloud Secrets Engine ist die beste Option für das DevOps-Team, um VMs in GCP über eine CICD-Pipeline bereitzustellen und Vault zum Schutz der vom Tool verwendeten Anmeldeinformationen zu integrieren. Die Google Cloud Secrets Engine kann dynamisch GCP-Service-Kontoschlüssel oder OAuth-Tokens basierend auf IAM-Richtlinien generieren, die zur Authentifizierung und Autorisierung des CICD-Tools für den Zugriff auf GCP-Ressourcen verwendet werden können. Die Berechtigungsnachweise werden automatisch widerrufen, wenn sie nicht mehr verwendet werden oder die Lease abläuft, um sicherzustellen, dass die Berechtigungsnachweise kurzlebig und sicher sind. Das DevOps-Team kann Rollensätze oder statische Konten in Vault konfigurieren, um den Umfang und die Berechtigungen der Anmeldeinformationen zu definieren, und die Vault-API oder CLI verwenden, um Anmeldeinformationen bei Bedarf anzufordern. Die Google Cloud Secrets Engine unterstützt auch die Generierung von Zugriffstokens für verkörperte Servicekonten, was für die Delegierung des Zugriffs auf andere Servicekonten nützlich sein kann, ohne deren Schlüssel zu speichern oder zu verwalten1.
Die Identity Secrets Engine ist für diesen Anwendungsfall keine gute Option, da sie keine GCP-Anmeldeinformationen generiert, sondern Identitäts-Token, die für den Zugriff auf andere Vault Secrets Engines oder Namespaces verwendet werden können2. Die Key/Value Secrets Engine Version 2 ist ebenfalls keine gute Option, da sie keine dynamischen Anmeldeinformationen generiert, sondern statische Geheimnisse speichert und verwaltet, die der Benutzer bereitstellt3. Die SSH Secrets Engine ist ebenfalls keine gute Option, da sie keine GCP-Anmeldeinformationen generiert, sondern SSH-Schlüssel oder OTPs, die für den Zugriff auf Remote-Hosts über SSH verwendet werden können4.
Referenz:
Google Cloud - Secrets Engines | Vault | HashiCorp Developer
Identität - Secrets Engines | Vault | HashiCorp Entwickler
KV - Secrets Engines | Vault | HashiCorp Entwickler
SSH - Secrets Engines | Vault | HashiCorp Entwickler

Die Transitgeheimnis-Engine ist keine gute Lösung für Binärdateien dieser Größe, da sie für kryptografische Funktionen für Daten auf dem Transportweg und nicht für Daten im Ruhezustand konzipiert ist. Die Transit-Secret-Engine speichert keine an sie gesendeten Daten, so dass es erforderlich wäre, den gesamten 2-GB-Blob zur Ver- oder Entschlüsselung an Vault zu senden, was ineffizient und unpraktisch wäre. Eine bessere Lösung wäre die Verwendung der Transitgeheimnis-Engine zur Generierung eines Datenschlüssels, d. h. eines Schlüssels mit hoher Entropie, der zur lokalen Ver- oder Entschlüsselung von Daten verwendet werden kann. Der Datenschlüssel kann je nach Anwendungsfall im Klartext zurückgegeben oder mit einem anderen Schlüssel umhüllt werden. Auf diese Weise kümmert sich das Transitgeheimnismodul nur um die Ver- oder Entschlüsselung des Datenschlüssels, nicht aber um die Daten selbst, und die Daten können in einem beliebigen primären Datenspeicher gespeichert werden. Referenz: Transit - Secrets Engines | Vault | HashiCorp Developer, Verschlüsselung als Dienst: transit secrets engine | Vault | HashiCorp Developer

Die Transitgeheimnis-Engine entlastet die Anwendungsentwickler von der Last der ordnungsgemäßen Ver- und Entschlüsselung und verlagert diese Last auf die Betreiber von Vault. Die Transit-Secrets-Engine bietet Verschlüsselung als Service, d. h. sie führt kryptografische Operationen an Daten während der Übertragung durch, ohne Daten zu speichern. Dies ermöglicht es Entwicklern, die Verantwortung für die Verwaltung von Verschlüsselungsschlüsseln und -algorithmen an die Betreiber von Vault zu delegieren, die Richtlinien für die Transit Secrets Engine definieren und durchsetzen können. Auf diese Weise können sich die Entwickler auf ihre Anwendungslogik und Daten konzentrieren, während Vault die Ver- und Entschlüsselung der Daten auf sichere und skalierbare Weise übernimmt. Referenz: Transit - Secrets Engines | Vault | HashiCorp Developer, Verschlüsselung als Service: Transit Secrets Engine | Vault | HashiCorp Developer