Nous avons développé cet atelier avec notre partenaire HashiCorp. Vos informations personnelles pourront être partagées avec HashiCorp, le collaborateur d'atelier, si vous avez accepté de recevoir des actualités sur les produits, des annonces et des offres sur la page de profil de votre compte.

GSP1004

Présentation

Vault utilise des règles pour régir le comportement des clients et instrumenter le contrôle des accès basé sur les rôles (RBAC) en spécifiant des droits d'accès (autorisation). Les règles permettent d'autoriser ou d'interdire l'accès à certains chemins et opérations de manière déclarative. Dans cet atelier pratique, vous allez apprendre à écrire et à utiliser des règles Vault.

Objectifs

Au cours de cet atelier, vous allez :

• créer des règles Vault ;
• gérer des règles Vault ;
• associer des règles Vault ;
• vérifier et tester des règles Vault.

Préparation

Avant de cliquer sur le bouton "Démarrer l'atelier"

Lisez ces instructions. Les ateliers sont minutés, et vous ne pouvez pas les mettre en pause. Le minuteur, qui démarre lorsque vous cliquez sur Démarrer l'atelier, indique combien de temps les ressources Google Cloud resteront accessibles.

Cet atelier pratique vous permet de suivre les activités dans un véritable environnement cloud, et non dans un environnement de simulation ou de démonstration. Des identifiants temporaires vous sont fournis pour vous permettre de vous connecter à Google Cloud le temps de l'atelier.

Pour réaliser cet atelier :

• Vous devez avoir accès à un navigateur Internet standard (nous vous recommandons d'utiliser Chrome).

Remarque : Ouvrez une fenêtre de navigateur en mode incognito (recommandé) ou de navigation privée pour effectuer cet atelier. Vous éviterez ainsi les conflits entre votre compte personnel et le compte temporaire de participant, qui pourraient entraîner des frais supplémentaires facturés sur votre compte personnel.

• Vous disposez d'un temps limité. N'oubliez pas qu'une fois l'atelier commencé, vous ne pouvez pas le mettre en pause.

Remarque : Utilisez uniquement le compte de participant pour cet atelier. Si vous utilisez un autre compte Google Cloud, des frais peuvent être facturés à ce compte.

Démarrer l'atelier et se connecter à la console Google Cloud

1. Cliquez sur le bouton Démarrer l'atelier. Si l'atelier est payant, une boîte de dialogue s'affiche pour vous permettre de sélectionner un mode de paiement. Sur la droite, vous trouverez le panneau Préparation et accès à l'atelier, qui contient les éléments suivants :

   • Le bouton Ouvrir la console Google Cloud
   • Les identifiants temporaires (nom d'utilisateur et mot de passe) que vous devez utiliser pour cet atelier
   • Des informations complémentaires vous permettant d'effectuer l'atelier, si nécessaire

   Notez que le minuteur de l'atelier se trouve en haut de la page et indique le temps restant.

2. Cliquez sur Ouvrir la console Google Cloud (ou effectuez un clic droit et sélectionnez Ouvrir le lien dans une fenêtre en navigation privée si vous utilisez Chrome).

   L'atelier lance les ressources, puis ouvre la page "Se connecter" dans un nouvel onglet.

   Conseil : Réorganisez les onglets dans des fenêtres distinctes, placées côte à côte.

   Remarque : Si la boîte de dialogue Sélectionner un compte s'affiche, cliquez sur Utiliser un autre compte.

3. Si nécessaire, copiez le nom d'utilisateur ci-dessous et collez-le dans la boîte de dialogue Se connecter.

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

   Vous trouverez également le nom d'utilisateur dans le panneau Préparation et accès à l'atelier.

4. Cliquez sur Suivant.

5. Copiez le mot de passe ci-dessous et collez-le dans la boîte de dialogue Bienvenue.

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

   Vous trouverez également le mot de passe dans le panneau Préparation et accès à l'atelier.

6. Cliquez sur Suivant.

   Important : Vous devez utiliser les identifiants fournis pour l'atelier. N'utilisez pas les identifiants de votre compte Google Cloud. Remarque : Si vous utilisez votre propre compte Google Cloud pour cet atelier, des frais supplémentaires pourront vous être facturés.

7. Accédez aux pages suivantes :

   • Acceptez les conditions d'utilisation.
   • N'ajoutez pas d'options de récupération ni d'authentification à deux facteurs (ce compte est temporaire).
   • Ne vous inscrivez pas à des essais sans frais.

Après quelques instants, la console Cloud s'ouvre dans cet onglet.

Remarque : Pour accéder aux produits et services Google Cloud, cliquez sur le menu de navigation ou saisissez le nom du service ou du produit dans le champ Recherche.

Activer Cloud Shell

Cloud Shell est une machine virtuelle qui contient de nombreux outils pour les développeurs. Elle comprend un répertoire d'accueil persistant de 5 Go et s'exécute sur Google Cloud. Cloud Shell vous permet d'accéder via une ligne de commande à vos ressources Google Cloud.

1. Cliquez sur Activer Cloud Shell  en haut de la console Google Cloud.

2. Passez les fenêtres suivantes :

   • Accédez à la fenêtre d'informations de Cloud Shell.
   • Autorisez Cloud Shell à utiliser vos identifiants pour effectuer des appels d'API Google Cloud.

Une fois connecté, vous êtes en principe authentifié et le projet est défini sur votre ID_PROJET : . Le résultat contient une ligne qui déclare l'ID_PROJET pour cette session :

Your Cloud Platform project in this session is set to {{{project_0.project_id | "PROJECT_ID"}}}

gcloud est l'outil de ligne de commande pour Google Cloud. Il est préinstallé sur Cloud Shell et permet la complétion par tabulation.

3. (Facultatif) Vous pouvez lister les noms des comptes actifs à l'aide de cette commande :

gcloud auth list

4. Cliquez sur Autoriser.

Résultat :

ACTIVE: * ACCOUNT: {{{user_0.username | "ACCOUNT"}}} To set the active account, run: $ gcloud config set account `ACCOUNT`

5. (Facultatif) Vous pouvez lister les ID de projet à l'aide de cette commande :

gcloud config list project

Résultat :

[core] project = {{{project_0.project_id | "PROJECT_ID"}}} Remarque : Pour consulter la documentation complète sur gcloud, dans Google Cloud, accédez au guide de présentation de la gcloud CLI.

Tâche 1 : Installer Vault

1. Dans Cloud Shell, ajoutez la clé GPG HashiCorp :

curl -fsSL https://apt.releases.hashicorp.com/gpg | sudo apt-key add - Remarque : Si un avertissement s'affiche, vous pouvez l'ignorer.

2. Ajoutez le dépôt Linux officiel de HashiCorp :

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

3. Mettez à jour et installez Vault :

sudo apt-get update sudo apt-get install vault

Vérifier l'installation

Après avoir installé Vault, vérifiez que l'installation s'est bien déroulée en vous assurant que le binaire Vault est disponible.

• Exécutez la commande vault pour vérifier l'installation :

vault

Le résultat obtenu doit ressembler à ceci :

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

Tâche 2 : Démarrer le serveur Vault

Une fois Vault installé, l'étape suivante consiste à démarrer un serveur Vault.

Vault fonctionne comme une application client/serveur. Le serveur Vault est le seul élément de l'architecture Vault qui interagit avec le stockage de données et les backends. Toutes les opérations effectuées avec la CLI Vault communiquent avec le serveur par le biais d'une connexion TLS.

Dans cet atelier, vous allez démarrer le serveur Vault en mode Développement et interagir avec lui.

Ce serveur en mode Développement ne nécessite aucune configuration supplémentaire, et votre CLI Vault locale sera authentifiée pour communiquer avec lui. Vous pouvez ainsi facilement tester Vault ou démarrer une instance Vault pour le développement. Toutes les fonctionnalités de Vault sont disponibles en mode Développement. Le flag -dev permet de contourner une grande partie de la configuration pour utiliser des valeurs par défaut non sécurisées.

Avertissement : N'exécutez jamais un serveur en mode Développement en production. Il n'est pas sécurisé et perdra les données à chaque redémarrage (car il les stocke en mémoire). Il est uniquement destiné au développement ou à l'expérimentation.

Démarrer le serveur de développement

Commencez par démarrer un serveur de développement Vault. Il s'agit d'un serveur intégré et préconfiguré qui est peu sécurisé, mais qui est utile pour tester Vault en local.

1. Pour le démarrer, exécutez la commande suivante :

vault server -dev

Vous devriez voir des informations concernant la configuration de votre serveur Vault. Notez que les valeurs Unseal Key (clé de descellement) et Root Token (jeton racine) s'affichent :

==> 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! Remarque : Le serveur de développement stocke toutes ses données en mémoire (mais toujours chiffrées). Il écoute sur localhost sans TLS, et descelle et affiche automatiquement la clé de descellement et la clé d'accès racine. Remarque : Opération non sécurisée

N'exécutez pas de serveur de développement Vault en production ! Cette méthode n'est utilisée ici que pour simplifier le processus de descellement pour cette démonstration.

Maintenant que le serveur de développement Vault est en cours d'exécution, vous pouvez continuer à configurer l'accès à celui-ci.

2. Ouvrez un nouvel onglet Cloud Shell.

3. Copiez et exécutez la commande export VAULT_ADDR ... à partir du résultat du terminal. Cette commande configure le client Vault pour qu'il communique avec le serveur de développement :

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

La CLI Vault détermine à quels serveurs Vault envoyer des requêtes à l'aide de la variable d'environnement VAULT_ADDR.

Vérifier que le serveur est en cours d'exécution

• Vérifiez que le serveur est en cours d'exécution avec la commande vault status :

vault status

Si l'exécution s'est déroulée correctement, le résultat doit se présenter comme suit :

$ 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

Parfait ! Vous avez démarré votre premier serveur de développement Vault. Vous pouvez maintenant passer à la section suivante, dans laquelle vous allez apprendre à rédiger des règles Vault.

Tâche 3 : Règles Vault

Vault crée une règle root lors de l'initialisation. Elle permet d'effectuer n'importe quelle opération sur l'ensemble des chemins d'accès. Cette règle est attribuée au jeton root qui s'affiche une fois l'initialisation terminée. Cela permet de disposer d'un super-utilisateur initial pour activer les moteurs de secrets, définir des règles et configurer des méthodes d'authentification.

Vault crée également une règle default. Elle définit un ensemble commun de fonctionnalités qui permettent à un jeton de s'auto-examiner et de s'auto-gérer. Cette règle est également attribuée au jeton root et est associée à tous les jetons par défaut.

Syntaxe des règles

Les règles sont écrites en HCL ou en JSON, et décrivent les chemins d'accès de Vault autorisés pour un utilisateur ou une machine. Une règle définit une liste de chemins. Chaque chemin d'accès définit les capacités autorisées. Les capacités d'un chemin d'accès doivent être explicitement accordées, car Vault refuse par défaut tout accès aux chemins afin d'assurer un système sécurisé par défaut.

Le format de base d'une règle est le suivant :

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

Voici une règle très simple qui accorde des droits de lecture pour le chemin d'accès "secret/foo" :

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

Lorsque cette règle est attribuée à un jeton, celui-ci obtient les droits de lecture sur le chemin "secret/foo". Toutefois, le jeton ne peut pas modifier ni supprimer "secret/foo", car les capacités ne le permettent pas. Comme les règles sont basées sur le principe du refus par défaut, le jeton ne disposerait d'aucun autre accès dans Vault. Cela signifie qu'une règle Vault vide n'accorde aucune autorisation dans le système.

Capacités

Une règle définit un ou plusieurs chemins d'accès et une liste de capacités autorisées. Chaque chemin d'accès doit définir une ou plusieurs capacités qui permettent de contrôler précisément les opérations autorisées (ou refusées). Comme vous le verrez dans les exemples ci-dessous, les capacités sont toujours spécifiées sous forme de liste de chaînes, même s'il n'y en a qu'une seule. La plupart de ces capacités correspondent aux verbes HTTP compatibles avec l'API Vault. Voici la liste des capacités :

Capacité de la règle	Verbes HTTP associés
create	POST/PUT
read	GET
update	POST/PUT
delete	DELETE
list	LIST
patch	PATCH
sudo	-
deny	-

La capacité sudo permet d'accéder aux chemins protégés par la racine (reportez-vous à la section du tutoriel Points de terminaison protégés par la racine). La capacité deny désactive l'accès au chemin. Lorsqu'elle est associée à d'autres capacités, elle prévaut systématiquement.

Exemples de règles

Une règle plus détaillée pour accorder tous les accès sur "secret/*" peut être définie comme suit :

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

Si vous souhaitez définir des restrictions supplémentaires, vous pouvez ajouter la capacité deny suivante :

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

Même si vous avez autorisé secret/*, cette ligne supplémentaire refuse explicitement secret/super-secret. Le refus est prioritaire.

Les règles peuvent également spécifier des paramètres allowed, disallowed et required. Ici, la clé "secret/restricted" ne peut contenir que "foo" (n'importe quelle valeur) et "bar" (soit "zip", soit "zap").

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

Les règles utilisent la correspondance de chemins pour tester l'ensemble des capacités par rapport à une requête. Un chemin de règle peut spécifier un chemin d'accès exact à mettre en correspondance, ou un modèle glob qui indique à Vault d'utiliser une correspondance de préfixe.

Par exemple, cette règle n'autorise la lecture que pour "secret/foo" ou "secret/foo/bar".

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

De plus, cette règle permet de lire tout ce qui se trouve sous "secret/bar". Un jeton associé pourrait lire "secret/bar/zip" ou "secret/bar/zip/zap", mais pas "secret/bars/zip".

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

En outre, cette règle permettrait de lire tout ce qui commence par le préfixe "zip-". Un jeton associé pourrait lire "secret/zip-zap" ou "secret/zip-zap/zong", mais pas "secret/zip/zap".

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

Enfin, le caractère + peut être utilisé pour désigner un nombre quelconque de caractères compris dans un seul segment de chemin. L'exemple suivant permettrait de lire le chemin "teamb" sous n'importe quel chemin de premier niveau sous secret/.

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

Et celui-ci permettrait de lire secret/foo/bar/teamb, secret/bar/foo/teamb, etc.

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

Comme vous pouvez le voir, l'architecture de Vault est semblable à celle d'un système de fichiers. Chaque action dans Vault possède un chemin et une capacité correspondants. Même les points de terminaison de configuration de base internes de Vault résident sous le chemin "sys/". Les règles définissent l'accès à ces chemins et capacités, ce qui contrôle l'accès d'un jeton aux identifiants dans Vault.

Règles basées sur des modèles

La syntaxe des règles permet d'effectuer un remplacement de variables dans certaines chaînes de règle avec des valeurs disponibles pour le jeton. Il est désormais possible d'injecter des informations identity. Et les clés path des règles permettent également l'injection. Pour l'instant, vous n'avez pas besoin de vous soucier des entités ou des alias. Ils sont simplement inclus à titre de référence pour plus tard.

Paramètres

Nom	Description
identity.entity.id	ID de l'entité
identity.entity.name	Nom de l'entité
identity.entity.metadata.<metadata key>	Métadonnées associées à l'entité pour la clé donnée
identity.entity.aliases.<mount accessor>.id	ID d'alias d'entité pour l'installation donnée
identity.entity.aliases.<mount accessor>.name	Nom d'alias d'entité pour l'installation donnée
identity.entity.aliases.<mount accessor>.metadata.<metadata key>	Métadonnées associées à l'alias pour l'installation et la clé de métadonnées spécifiées
identity.entity.aliases.<mount accessor>.custom_metadata.<custom_metadata key>	Métadonnées personnalisées associées à l'alias pour l'installation et la clé de métadonnées personnalisées spécifiées
identity.groups.ids.<group id>.name	Nom du groupe pour l'ID de groupe donné
identity.groups.names.<group name>.id	ID du groupe pour le nom de groupe donné
identity.groups.ids.<group id>.metadata.<metadata key>	Métadonnées associées au groupe pour la clé donnée
identity.groups.names.<group name>.metadata.<metadata key>	Métadonnées associées au groupe pour la clé donnée

Exemples

La règle suivante crée une section du moteur de secrets KVv2 pour un utilisateur spécifique :

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

Pour en savoir plus sur les règles basées sur des modèles, consultez la documentation correspondante.

Remarque : Lorsque vous développez des règles basées sur des modèles, utilisez des ID dans la mesure du possible. Chaque ID est unique pour l'utilisateur, tandis que les noms peuvent changer dans le temps et être réutilisés. Ainsi, si le nom d'un utilisateur ou d'un groupe est modifié, la règle sera mappée à l'entité ou au groupe prévus.

Vérifier les capacités des règles intégrées

Maintenant que vous avez vu comment les règles sont écrites, examinons rapidement les capacités des règles root et default.

1. Dans l'onglet Cloud Shell ouvert, exécutez la commande suivante pour vous connecter à Vault avec votre jeton racine :

vault login token=<your root token>

Vous devriez obtenir le résultat suivant :

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"] Remarque : Notez que la règle associée est la règle root.

2. Puisque la règle root vous permet de tout faire dans Vault, exécutez une commande de base pour le vérifier :

vault secrets list

Le résultat doit se présenter comme suit :

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..

Vous allez maintenant essayer d'exécuter la même commande en tant qu'utilisateur auquel seule la règle default est associée.

3. Commencez par activer la méthode d'authentification userpass et par créer un utilisateur :

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

4. Ensuite, connectez-vous à Vault avec l'utilisateur que vous venez de créer :

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

Vous devriez obtenir le résultat suivant :

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 Remarque : Notez que la règle associée est la règle default.

5. Exécutez la même commande que précédemment pour vérifier les capacités de la règle :

vault secrets list

Vous devriez recevoir l'erreur suivante :

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

Comme vous pouvez le voir ici, Vault effectue une requête API GET sur sys/mounts. Comme vous recevez une erreur d'autorisation refusée, vous ne pouvez pas accéder au chemin d'accès ni lister les moteurs de secrets. Il est maintenant temps d'écrire votre première règle pour accéder à ce chemin et lister les moteurs de secrets.

Tâche 4 : Créer une règle

Étant donné que Vault sécurise, stocke et contrôle de manière centralisée l'accès aux secrets au niveau de l'infrastructure et des applications distribuées, il est essentiel de contrôler les autorisations avant qu'un utilisateur ou une machine n'obtienne un accès.

La solution consiste à restreindre l'utilisation de la règle root et à rédiger des règles précises pour appliquer le principe du moindre privilège. Par exemple, si une application récupère des identifiants Google Cloud depuis Vault, rédigez une règle autorisant la lecture depuis le moteur de secrets Google Cloud, mais interdisant la suppression, etc.

Les règles sont associées à des jetons et à des rôles pour appliquer les autorisations des clients sur Vault. Maintenant que vous avez vu comment les règles sont définies d'un point de vue syntaxique, il est temps d'écrire votre première règle Vault.

Se connecter à l'UI Web de Vault

1. Tout d'abord, cliquez sur l'icône Aperçu sur le Web dans la barre d'outils de Cloud Shell.

2. Cliquez sur Modifier le port.

3. Remplacez le numéro de port par 8200 et cliquez sur Modifier et prévisualiser.

4. Vous êtes redirigé vers la page de connexion Vault.

5. Saisissez le jeton racine que vous avez enregistré précédemment dans l'atelier, puis cliquez sur Se connecter.

Votre serveur de développement Vault doit se présenter comme suit.

Maintenant que vous êtes connecté à l'UI Web du serveur de développement, vous pouvez passer à la section suivante.

Créer une règle

1. Sur la page d'accueil, cliquez sur Access control (Contrôle des accès). Vous devriez voir les règles LCA default et root.

2. Cliquez sur Create ACL policy (Créer une règle LCA).

3. Commencez par nommer votre règle demo-policy.

Vous pouvez maintenant commencer à rédiger votre règle. Dans la section précédente, vous n'avez pas pu accéder au chemin d'accès sys/mounts pour lire les moteurs de secrets. Vous allez ajouter cette autorisation.

4. Dans Policy rules (Règles), sélectionnez Code editor (Éditeur de code) et ajoutez le code d'espace réservé suivant :

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

5. Commençons par modifier l'élément path pour qu'il pointe vers le chemin sys/mounts auquel vous avez essayé d'accéder précédemment :

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

6. Vous allez ensuite ajouter une capacité. Comme Vault tente d'effectuer un appel d'API GET sur ce chemin, vous devez disposer de la capacité read. Ajoutez read à la liste des capacités :

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

Votre règle doit se présenter comme suit :

7. Cliquez sur Create policy (Créer la règle).

Vous devez maintenant associer cette règle à l'utilisateur example-user que vous avez créé précédemment.

8. Cliquez sur Back to main navigation (Retour à la navigation principale).

9. Cliquez sur Access > Authentication methods (Accès > Méthodes d'authentification) dans le volet de gauche, puis sur userpass.

10. Cliquez sur les trois points à côté de l'utilisateur example-user, puis sélectionnez Edit user (Modifier l'utilisateur).

11. Sous le champ "Password" (Mot de passe), cliquez sur Tokens (Jetons) pour ouvrir le sous-menu.

12. Sous Generated Token's Policies (Règles du jeton généré), ajoutez la règle que vous venez de créer (demo-policy) et cliquez sur Add (Ajouter).

13. Cliquez sur Save (Enregistrer).

Parfait ! Vous avez créé une règle et vous l'avez associée à l'utilisateur example-user.

14. Revenez dans Cloud Shell et exécutez à nouveau la commande suivante :

vault secrets list

Vous remarquerez la même erreur que précédemment :

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

Pourquoi une erreur s'est-elle produite après l'ajout de la règle à l'utilisateur ? C'est dû au fait que lorsque vous associez une nouvelle règle à un utilisateur, elle n'est pas associée au jeton existant pour cet utilisateur. Pour résoudre ce problème, vous devez générer un nouveau jeton pour cet utilisateur afin d'y associer la nouvelle règle.

15. Exécutez la commande suivante pour vous connecter et générer un nouveau jeton pour example-user :

vault login -method=userpass username=example-user password=password! Remarque : Vous devriez recevoir un nouveau jeton comme résultat. Vous pouvez constater que les règles default et demo-policy sont désormais associées. 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. Maintenant, tentez de lister les moteurs de secrets une nouvelle fois :

vault secrets list

Le résultat doit se présenter comme suit :

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. Vous pouvez également vérifier les capacités du jeton à l'aide de la commande vault token capabilities. Exécutez la commande suivante pour vérifier votre règle sur le chemin sys/mounts :

vault token capabilities <your token> sys/mounts

Vous devez obtenir le résultat suivant :

read

18. Ensuite, vérifiez les capacités du jeton pour le chemin sys/policies/acl :

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

Vous devez obtenir le résultat suivant :

deny

19. Pour cela, essayez d'exécuter la commande suivante pour lister les règles :

vault policy list

Vous devriez recevoir l'erreur suivante :

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

Comme vous pouvez le voir, vous obtenez une erreur d'autorisation refusée pour une requête API GET sur le chemin sys/policies/acl. Notez également l'ajout de list=true au chemin. Vous devrez également ajouter cette capacité. Corrigeons cela en modifiant la règle existante.

20. Revenez à la règle demo-policy que vous avez créée dans l'UI de Vault.

21. Cliquez sur Edit policy (Modifier la règle).

22. Dans la zone Policy (Règle), ajoutez le code d'espace réservé suivant sous la règle existante que vous avez écrite :

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

23. Commençons par modifier l'élément path pour qu'il pointe vers le chemin sys/policies/acl auquel vous essayiez d'accéder :

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

24. Vous allez maintenant ajouter la capacité. Comme Vault tente d'effectuer un appel d'API GET sur ce chemin, vous devez ajouter à nouveau la capacité read. De plus, cette tentative a transmis le paramètre list=true dans l'URL. Vous devez donc également ajouter cette capacité.

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

Votre règle modifiée doit maintenant ressembler à ceci :

25. Cliquez sur Save (Enregistrer).

26. Revenez dans Cloud Shell et exécutez à nouveau la commande suivante :

vault policy list

Le résultat doit se présenter comme suit :

default default-ceiling demo-policy root

27. Exécutez la commande suivante pour copier les valeurs des règles dans un fichier texte :

vault policy list > policies.txt

28. Enfin, vérifiez à nouveau les capacités du jeton pour le chemin d'accès sys/policies/acl :

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

Vous devez obtenir le résultat suivant :

list, read

29. Exécutez la commande suivante pour copier les valeurs des règles dans un fichier texte. Veillez à remplacer <your token> par la valeur de votre jeton :

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

30. Exécutez les commandes suivantes pour copier les fichiers texte policies et token_capabilities dans un bucket Cloud Storage créé au préalable afin de suivre votre progression :

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

Comme vous pouvez le voir, lorsque vous avez modifié la règle existante associée à l'utilisateur, les changements ont été pris en compte sans générer de nouveau jeton. En effet, le contenu des règles est analysé en temps réel chaque fois que le jeton est utilisé. Par conséquent, si une règle est modifiée, les éléments qui ont changé seront appliqués la prochaine fois qu'un jeton, auquel cette règle est associée, sera utilisé pour effectuer un appel à Vault.

Parfait ! Vous avez créé une règle qui accorde un accès en lecture au chemin sys/mounts et vous l'avez associée à un utilisateur. Vous avez ensuite ajouté une règle pour accorder l'accès en lecture au chemin sys/policies et permettre de générer une liste.

Cliquez sur Vérifier ma progression pour valider l'objectif. Créer des règles

Tâche 5 : Gérer des règles

Les règles sont rédigées (écrites) dans l'éditeur de votre choix. Elles peuvent être rédigées en HCL ou en JSON, et la syntaxe est décrite en détail ci-dessus. Une fois enregistrées, les règles doivent être importées dans Vault avant de pouvoir être utilisées.

Dans la section précédente, vous avez utilisé l'UI pour rédiger et gérer une règle. Cette section présente les commandes CLI permettant de gérer les règles.

• Tout d'abord, veillez à exécuter la commande suivante dans Cloud Shell pour vous connecter à Vault avec votre jeton racine :

vault login <your root token>

Lister les règles

• Exécutez la commande suivante pour lister toutes les règles enregistrées dans Vault :

vault read sys/policy

Vous devriez obtenir le résultat suivant :

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

Créer des règles

Les règles peuvent être créées (importées) avec la CLI, l'UI ou l'API. Dans la section précédente, vous avez simplement utilisé l'UI pour créer le fichier HCL.

Pour créer une règle dans Vault, vous devez utiliser la commande suivante :

vault policy write policy-name policy-file.hcl

1. Pour tester cela, commencez par créer un fichier de règle de base à l'aide de la commande suivante :

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. Vérifiez que votre fichier a été créé correctement :

cat example-policy.hcl

3. Créez maintenant une règle nommée example-policy à l'aide de la commande vault policy write :

vault policy write example-policy example-policy.hcl

Si l'opération réussit, vous devriez obtenir le résultat suivant :

Success! Uploaded policy: example-policy

Dans cet exemple, le nom de la règle est "example-policy". Vous pouvez considérer ce nom comme un pointeur ou un lien symbolique vers les règles LCA. Les jetons sont associés à des règles par leur nom, lesquelles sont ensuite mappées à l'ensemble de règles correspondant à ce nom.

Modifier des règles

Il est possible de modifier les règles existantes pour changer les autorisations avec la CLI ou l'API. Pour modifier une règle existante dans Vault, vous devez suivre les mêmes étapes que pour créer une règle, mais en utilisant le nom d'une règle existante.

1. Exécutez d'abord la commande suivante pour modifier et remplacer votre fichier de règle existant afin de pouvoir lister les méthodes d'authentification :

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. Vérifiez que votre fichier a été créé correctement :

cat example-policy.hcl

3. Modifiez votre règle :

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

Parfait ! Vous avez modifié une règle à l'aide de la CLI.

4. Exécutez la commande suivante pour copier le fichier de règle dans un bucket Cloud Storage créé au préalable afin de suivre votre progression :

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

Cliquez sur Vérifier ma progression pour valider l'objectif. Créer et gérer des règles à l'aide de commandes CLI

Supprimer des règles

Il est possible de supprimer des règles existantes avec la CLI, l'UI ou l'API. Pour supprimer une règle, exécutez la commande suivante :

vault delete sys/policy/policy-name

1. Essayons de mettre tout cela en pratique. Exécutez la commande suivante pour supprimer la règle que vous venez de créer :

vault delete sys/policy/example-policy

Si l'opération a réussi, vous devriez obtenir le résultat suivant :

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

2. Listez vos règles à l'aide de la commande suivante :

vault policy list

Vous devriez obtenir le résultat suivant :

default default-ceiling demo-policy root

Parfait ! Vous avez bien supprimé la règle example-policy.

Remarque : Il s'agit d'une opération idempotente. Vault ne renvoie pas d'erreur lors de la suppression d'une règle qui n'existe pas.

Tâche 6 : Associer des règles

Vault peut associer automatiquement un ensemble de règles à un jeton en fonction d'une autorisation. Cette configuration varie considérablement selon les backends d'authentification. Par souci de simplicité, cet exemple utilise la méthode d'authentification userpass intégrée à Vault.

1. Exécutez la commande suivante pour créer l'utilisateur firstname-lastname dans Vault avec une liste de règles associées :

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

Cela crée un mappage d'authentification vers la règle. Ainsi, lorsque l'utilisateur s'authentifie auprès de Vault, il reçoit un jeton auquel est associée la liste des règles.

2. Authentifiez-vous auprès de Vault en exécutant la commande suivante :

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

Vous devriez obtenir le résultat suivant :

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

Comme les informations fournies sont correctes, Vault génère un jeton, lui attribue la liste des règles configurées et le renvoie à l'utilisateur authentifié.

Jetons

Les jetons possèdent deux ensembles de règles : les règles d'identité, qui sont calculées en fonction de l'entité et de ses groupes, et les règles de jeton, qui sont soit définies en fonction de la méthode de connexion, soit, dans le cas de créations explicites de jetons avec l'API, fournies en tant qu'entrée lors de la création du jeton. Ce qui suit concerne exclusivement les règles de jeton : il n'est pas possible de contrôler les règles d'identité d'un jeton autrement qu'en modifiant les entités, les groupes et les appartenances à un groupe sous-jacents.

1. Commencez par vous reconnecter à Vault avec votre jeton racine :

vault login <your root token>

2. Les jetons sont associés à leurs règles au moment de la création. Exécutez la commande suivante pour créer un jeton avec les règles dev-readonly et logs :

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

Vous devriez obtenir le résultat suivant :

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"] Remarque : Vous pouvez ignorer les avertissements indiquant que les règles n'existent pas, car vous ne les avez pas encore créées.

Normalement, les seules règles qui peuvent être spécifiées sont celles qui sont présentes dans les règles du jeton actuel (c'est-à-dire le parent du nouveau jeton). Toutefois, les utilisateurs racine peuvent attribuer n'importe quelle règle.

Il n'est pas possible de modifier les règles associées à un jeton une fois qu'il a été émis. Le jeton doit être révoqué et un nouveau jeton doit être acquis pour recevoir un nouvel ensemble de règles.

Cependant, le contenu des règles est analysé en temps réel chaque fois que le jeton est utilisé. Par conséquent, si une règle est modifiée, les éléments qui ont changé seront appliqués la prochaine fois qu'un jeton, auquel cette règle est associée, sera utilisé pour effectuer un appel à Vault.

Tâche 7 : Règles pour les secrets

Dans cette section, vous allez créer des règles Vault pour accorder aux utilisateurs différents niveaux d'accès dans Vault, puis les tester.

• Dans Cloud Shell, commencez par créer plusieurs utilisateurs avec des règles différentes :

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"

Maintenant que vous avez créé des utilisateurs, vous allez créer les règles que vous leur avez déjà associées. Vous allez commencer par la règle admin, qui doit pouvoir accéder sans limites à tous les secrets de Vault.

Créer la règle admin

Pour les besoins de cet atelier, un utilisateur admin doit pouvoir :

• lire la vérification de l'état du système ;
• créer et gérer des règles LCA de manière globale dans Vault ;
• activer et gérer les méthodes d'authentification de manière globale dans Vault ;
• gérer le moteur de secrets Key-Value activé au chemin secret/.

1. Dans l'UI de Vault, accédez à ACL policies (Règles LCA) dans le volet de gauche. Vous devriez voir les règles default, default-ceiling, demo-policy et root.

2. Cliquez sur Create ACL policy (Créer une règle LCA).

3. Commencez par nommer votre règle admin.

4. Dans Policy rules (Règles), sélectionnez Code editor (Éditeur de code) et ajoutez le code suivant :

# 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"] }

Votre règle doit se présenter comme suit :

5. Cliquez sur Create policy (Créer la règle).

Créer la règle appdev

Pour les besoins de cet atelier, un utilisateur appdev doit pouvoir :

• créer, lire et modifier des moteurs de secrets ;
• gérer le moteur de secrets Key-Value activé au chemin secret/appdev/.

1. Revenez à la page ACL Policies (Règles LCA).

2. Cliquez sur Create ACL policy (Créer une règle LCA).

3. Commencez par nommer votre règle appdev.

4. Dans Policy rules (Règles), sélectionnez Code editor (Éditeur de code) et ajoutez le code suivant :

# 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. Cliquez sur Create policy (Créer la règle).

Créer la règle security

Pour les besoins de cet atelier, un utilisateur security :

• doit pouvoir créer et gérer des règles LCA de manière globale dans Vault ;
• doit pouvoir gérer les moteurs de secrets ;
• doit pouvoir gérer le moteur de secrets Key-Value activé au chemin secret/ ;
• ne doit pas pouvoir accéder en lecture aux secrets du chemin secret/admin ni les lister.

1. Revenez à la page ACL Policies (Règles LCA).

2. Cliquez sur Create ACL policy (Créer une règle LCA).

3. Commencez par nommer votre règle security.

4. Dans Policy rules (Règles), sélectionnez Code editor (Éditeur de code) et ajoutez le code suivant :

# 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. Cliquez sur Create policy (Créer la règle).

Créer des secrets

Maintenant que vous avez créé les différentes règles, il est temps de créer des secrets.

1. Revenez dans Cloud Shell et exécutez les commandes suivantes pour créer des secrets dans le chemin secret/security :

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

2. Créez des secrets dans le chemin secret/appdev :

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

3. Créez des secrets dans le chemin secret/admin :

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

Vérifier la sécurité pour appdev

Maintenant que vous avez créé des secrets, vérifions que ces règles sont appliquées. Vous allez d'abord vous connecter en tant qu'utilisateur app-dev et voir à quoi vous avez accès.

1. Exécutez la commande suivante pour vous connecter en tant qu'utilisateur app-dev :

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

2. Essayez maintenant de récupérer le secret appdev/first :

vault kv get secret/appdev/first

Vous devriez obtenir le résultat suivant :

======= 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. Récupérez le secret situé à l'emplacement secret/appdev/beta-app/second :

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

Vous devriez obtenir le résultat suivant :

======= 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. Créez un secret :

vault kv put secret/appdev/appcreds credentials=creds123

5. Détruisez le secret :

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

6. Essayez d'obtenir un secret depuis le chemin secret/security :

vault kv get secret/security/first

Vous devriez recevoir l'erreur suivante :

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. Essayez de lister tous les secrets à l'emplacement secret/ :

vault kv list secret/

Vous devriez à nouveau recevoir une erreur :

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

Parfait ! Vous avez pu récupérer et créer des secrets dans le chemin secret/appdev, et vous avez vérifié que vous ne pouviez pas accéder aux secrets en dehors de ce chemin.

Vérifier la règle pour security

1. Exécutez la commande suivante pour vous connecter en tant qu'utilisateur security :

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

2. Essayez maintenant de récupérer le secret security/first :

vault kv get secret/security/first

Vous devriez obtenir le résultat suivant :

======= 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. Récupérez le secret situé à l'emplacement secret/security/second :

vault kv get secret/security/second

Vous devriez obtenir le résultat suivant :

======= 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. Créez un secret dans secret/security/supersecure :

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

5. Détruisez le secret :

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

6. Essayez de lire un secret depuis le chemin secret/appdev :

vault kv get secret/appdev/first

Vous devriez obtenir le résultat suivant :

======= 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. Essayez de lister tous les secrets à l'emplacement secret/ :

vault kv list secret/

Vous devriez obtenir le résultat suivant :

Keys ---- admin/ appdev/ security/

8. Activez un nouveau moteur de secrets :

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

9. Essayez d'accéder au secret secret/admin/first :

vault kv get secret/admin/first

Vous devriez recevoir l'erreur suivante :

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. Essayez de lister les secrets à l'emplacement secret/admin :

vault kv list secret/admin

Là encore, vous devriez recevoir une erreur :

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

Parfait ! Vous pouvez récupérer et créer des secrets dans le chemin secret/, activer un moteur de secrets, et l'accès au chemin secret/admin vous a été refusé, comme spécifié dans la règle.

Vérifier la règle pour admin

1. Exécutez la commande suivante pour vous connecter en tant qu'utilisateur admin :

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

2. Essayez maintenant de récupérer le secret admin/first :

vault kv get secret/admin/first

Vous devriez obtenir le résultat suivant :

======= 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. Récupérez un secret situé à l'emplacement secret/security/first :

vault kv get secret/security/first

Vous devriez obtenir le résultat suivant :

======= 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. Créez un secret :

vault kv put secret/webserver/credentials web=awesome

5. Détruisez le secret :

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

6. Essayez d'obtenir des secrets à partir de l'emplacement secret/appdev :

vault kv get secret/appdev/first

Vous devriez obtenir le résultat suivant :

======= 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. Essayez de lister tous les secrets à l'emplacement secret/appdev :

vault kv list secret/appdev/

Vous devriez obtenir le résultat suivant :

Keys ---- appcreds beta-app/ first

8. Listez toutes les règles :

vault policy list

Vous devriez obtenir le résultat suivant :

admin appdev default default-ceiling demo-policy security root

9. Exécutez la commande suivante pour copier les valeurs des règles dans un fichier texte et l'importer dans le bucket Cloud Storage :

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

10. Activez la méthode d'authentification gcp :

vault auth enable gcp

11. Enfin, listez les méthodes d'authentification activées :

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

Parfait ! Vous avez vérifié que vous disposez des droits d'administrateur associés à la règle que vous avez rédigée.

Cliquez sur Vérifier ma progression pour valider l'objectif. Règles pour les secrets

Chemins d'accès

Comme vous avez pu le voir dans le code de la règle fourni pour l'utilisateur security, deux éléments que vous n'avez pas encore abordés ont été introduits : data/ et metadata/.

Le point de terminaison du chemin metadata/ renvoie une liste de noms de clés à l'emplacement spécifié. Notez également que les valeurs elles-mêmes ne sont pas accessibles avec cette commande. Les versions de lecture et d'écriture sont précédées du préfixe data/. Voici comment lister, lire et détruire des secrets :

• Écrire et lire des versions : data/
• Lister les clés : metadata/
• Lire les versions : metadata/
• Détruire des versions de secret : destroy/
• Détruire toutes les versions des métadonnées d'une clé : metadata/

Par exemple, si vous essayez de refuser l'accès à un secret situé à l'emplacement secret/example, vous devez utiliser le format suivant avec data/ :

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

Si vous souhaitez refuser l'accès à la liste dans secret/examples, vous devez utiliser le format suivant avec metadata/ :

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

Tâche 8 : Contrôle ultraprécis

En plus de l'ensemble standard de capacités, Vault offre un contrôle plus précis des autorisations sur un chemin donné. Les capacités associées à un chemin prévalent sur les autorisations des paramètres.

Contraintes de paramètres

Dans Vault, les données sont représentées sous la forme de paires key=value. Les règles Vault peuvent éventuellement restreindre davantage les chemins en se basant sur les clés et les données associées à ces clés lors de l'évaluation des permissions pour un chemin. Les options de contrôle plus précises sont les suivantes :

• required_parameters : liste des paramètres qui doivent être spécifiés.
• allowed_parameters : liste de clés et de valeurs autorisées sur le chemin donné.
• denied_parameters : ajoute un paramètre et ses valeurs à une liste de blocage. Toutes les valeurs spécifiées ici prévalent sur allowed_parameters.

Pour en savoir plus sur le contrôle ultraprécis, consultez la documentation correspondante.

Félicitations !

Comme vous pouvez le voir, les règles sont un élément important de Vault. Bien que l'utilisation du jeton racine soit la méthode la plus simple pour démarrer, vous devrez rapidement restreindre l'accès à Vault, et le système de règles est le moyen d'y parvenir.

La syntaxe et le fonctionnement des règles sont faciles à comprendre et à appliquer. Et comme toutes les méthodes d'authentification doivent se rattacher au système de règles central, vous n'avez besoin d'apprendre à utiliser que ce seul système de règles.

Dans cet atelier, vous avez créé et géré des règles, vous les avez associées à des utilisateurs et des jetons, et vous avez vérifié leurs autorisations.

Étapes suivantes et informations supplémentaires

Pour en savoir plus sur Vault, consultez les ressources suivantes :

• Tutoriels de démarrage Vault
• Documentation Vault
• Documentation sur les règles Vault
• Tutoriel sur les règles Vault

Formations et certifications Google Cloud

Les formations et certifications Google Cloud vous aident à tirer pleinement parti des technologies Google Cloud. Nos cours portent sur les compétences techniques et les bonnes pratiques à suivre pour être rapidement opérationnel et poursuivre votre apprentissage. Nous proposons des formations pour tous les niveaux, à la demande, en salle et à distance, pour nous adapter aux emplois du temps de chacun. Les certifications vous permettent de valider et de démontrer vos compétences et votre expérience en matière de technologies Google Cloud.

Dernière mise à jour du manuel : 4 juin 2026

Dernier test de l'atelier : 4 juin 2026

Copyright 2026 Google LLC. Tous droits réservés. Google et le logo Google sont des marques de Google LLC. Tous les autres noms d'entreprises et de produits peuvent être des marques des entreprises auxquelles ils sont associés.