Introduction

Vault est une sorte de coffre fort. Celui-ci stocke des secrets sous forme d’arbre. Ceux-ci peuvent être un mot de passe, un token ou un compte MySQL selon le module utilisé.

Un système moderne nécessite l'accès à une multitude de secrets: informations d'identification de base de données, clés d'API pour les services externes, informations d'identification pour la communication d'architecture orientée services, etc.

Comprendre qui accède à quels secrets est déjà très difficile et spécifique à la plate-forme.

L'ajout d'un roulement de clé, d'un stockage sécurisé et de journaux d'audit détaillés est presque impossible sans une solution personnalisée.

C'est là que Vault intervient.

Vous trouverez ci-dessous les principales caractéristiques de Vault.

Secure secret storage : Par défaut, Vault crypte les secrets avant de les écrire dans un stockage persistant.
Support for dynamic secrets : Vault peut générer des secrets à la demande et les révoquer après la fin du bail.
Leasing and Renewal : Tous les secrets dans la chambre forte sont associés à un bail. Le secret est automatiquement révoqué à la fin du bail. Le renouvellement est possible grâce à des API de renouvellement intégrées.
Secrets Revocation : Vault peut révoquer non seulement des secrets uniques, mais aussi un arbre de secrets, par exemple tous les secrets lus par un utilisateur spécifique, ou tous les secrets d'un type particulier.

Nos serveurs vault seront définis par leur adresse IP uniquement, mais aussi référencés par un label :

Note:

Il convient que les serveurs soient déclarés dans le DNS ou que les entrées soit référencés dans le fichier /etc/hosts de chaque serveurs.

Hardware & Software

OS : CentOS 8
Cpu : 2 vCpu
Ram : 2 Go
HDD : 40 Go

Nommage et IP :

vault001 : 192.168.1.81
vault002 : 192.168.1.82

Stockage :

Pour la persistance de données,nous avons le choix entre :

le stockage local
une solution de clusturing.

C'est cette dernière qui sera utilisé. Pour cela, nous allons utiliser la solution “consul”, elle même développé par la société Hashicorp.

Nous devrons installer Consul en tant qu'agent sur les deux nœuds “vault”.

Installation du package “yum-config-manager” pour gérer vos dépôts.

$ sudo yum install -y yum-utils

Utilisez “yum-config-manager” pour ajouter le dépôt Linux officiel de HashiCorp.

$ sudo yum-config-manager --add-repo https://rpm.releases.hashicorp.com/RHEL/hashicorp.repo

Installation du package “consul”

$ sudo yum -y install consul

Pour vérifier que “Consul” est correctement installé, lancez “consul -v” sur le système.

# consul -v
Consul v1.8.0
Protocol 2 spoken by default, understands 2 to 3 (agent will automatically use protocol >2 when speaking to compatible agents)

Créer un répertoire pour stocker les données.

# mkdir -p /opt/consul
# chown -R consul:consul /opt/consul
# chmod -R 775 /opt/consul

Créez/Modifier ensuite le fichier de configuration “hcl” pour les deux dans “/etc/consul.d/consul.hcl”

# nano /etc/consul.d/consul.hcl

Dans l'optique de configuration l'agent avec notre cluster “consul”, voici un point de départ pour la configuration de base de l'agent Consul pour le premier nœud - “vault01”:

data_dir = "/opt/consul"
client_addr = "0.0.0.0"
node_name = "vault01"
datacenter = "oowy-dc-1"
bind_addr = "192.168.1.81"
retry_join = ["192.168.1.101", "192.168.1.102", "192.168.1.103"]
log_level = "INFO"
enable_syslog = true
encrypt = "pzDVYxESgPSkPhBFudHU5w=="
ca_file = "/etc/consul.d/consul-agent-ca.pem"
cert_file = "/etc/consul.d/oowy-dc-1-server-consul-0.pem"
key_file = "/etc/consul.d/oowy-dc-1-server-consul-0-key.pem"
verify_incoming = true
verify_outgoing = true
verify_server_hostname = true

Pour notre second nœud - “vault02”

data_dir = "/opt/consul"
client_addr = "0.0.0.0"
node_name = "vault02"
datacenter = "oowy-dc-1"
bind_addr = "192.168.1.82"
retry_join = ["192.168.1.101", "192.168.1.102", "192.168.1.103"]
log_level = "INFO"
enable_syslog = true
encrypt = "pzDVYxESgPSkPhBFudHU5w=="
ca_file = "/etc/consul.d/consul-agent-ca.pem"
cert_file = "/etc/consul.d/oowy-dc-1-server-consul-0.pem"
key_file = "/etc/consul.d/oowy-dc-1-server-consul-0-key.pem"
verify_incoming = true
verify_outgoing = true
verify_server_hostname = true

On vérifie la configuration

# consul validate /etc/consul.d/consul.hcl
Configuration is valid!

Nous démarrons nos agents “consul”. Il nous suffira de lancer le service consul sur nos deux nœuds.

Nous rendons le service automatique au lancement du serveur.

# systemctl enable consul

Démarrage du service “consul”

# systemctl start consul

On vérifie que nos agents remontent bien avec le cluster.

[root@vault001 ~]# consul members
Node       Address             Status  Type    Build  Protocol  DC   Segment
consul001  192.168.1.101:8301  alive   server  1.8.0  2         dc1  <all>
consul002  192.168.1.102:8301  alive   server  1.8.0  2         dc1  <all>
consul003  192.168.1.103:8301  alive   server  1.8.0  2         dc1  <all>
vault001   192.168.1.81:8301   alive   client  1.8.0  2         dc1  <default>
vault002   192.168.1.82:8301   alive   client  1.8.0  2         dc1  <default>

Note:

Installation à réaliser sur les deux nœuds vault

Installation du package “yum-config-manager” pour gérer vos dépôts.

# yum install -y yum-utils

Utilisez “yum-config-manager” pour ajouter le dépôt Linux officiel de HashiCorp.

# yum-config-manager --add-repo https://rpm.releases.hashicorp.com/RHEL/hashicorp.repo

Installation du package Vault

# yum -y install vault

Activer l'auto-complétion des commandes.

# vault -autocomplete-install
# complete -C /usr/local/bin/vault vault

Nous allons configurer nos nœuds Vault.

Pour le premier nœud : “vault01.oowy.lan”

# nano /etc/vault.d/vault.hcl
...
ui = true
...
disable_mlock = true
...
listener "tcp" {
  address          = "0.0.0.0:8200"
  tls_disable      = 1
}
 
storage "consul" {
  address = "127.0.0.1:8500"
  path    = "vault/"
}
 
api_addr = "http://192.168.1.82:8200"
cluster_addr = "http://192.168.1.82:8201"
 
max_lease_ttl         = "10h"
default_lease_ttl    = "10h"
disable_cache = true
cluster_name         = "vault"

Pour le second nœud : “vault02.oowy.lan”

# nano /etc/vault.d/vault.hcl
...
ui = true
...
disable_mlock = true
...
listener "tcp" {
  address          = "0.0.0.0:8200"
  tls_disable      = 1
}
 
storage "consul" {
  address = "127.0.0.1:8500"
  path    = "vault/"
}
 
api_addr = "http://192.168.1.82:8200"
cluster_addr = "http://192.168.1.82:8201"
 
max_lease_ttl         = "10h"
default_lease_ttl    = "10h"
disable_cache = true
cluster_name         = "vault"

max_lease_ttl - Spécifie la durée maximale de location possible pour les jetons et les secrets. Elle est spécifiée à l'aide d'un suffixe d'étiquette comme “30s” ou “1h”.
default_lease_ttl - Spécifie la durée de location par défaut pour les jetons et les secrets. Elle est spécifiée par un suffixe comme “30s” ou “1h”. Cette valeur ne peut pas être supérieure à max_lease_ttl.

On rend active le service au démarrage.

# systemctl enable vault

On démarre vault.

# systemctl start vault

Sur le premier nœud vault : “vault01.oowy.lan”

export VAULT_ADDR=http://127.0.0.1:8200
echo "export VAULT_ADDR=http://127.0.0.1:8200" >> ~/.bashrc

Initialisation de Vault avec la commande : “vault operator init”

Note:

On peut pousser la sortie de la commande dans un fichier

# vault operator init > /etc/vault.d/init.file

[root@vault001 ~]# vault operator init
Unseal Key 1: LKd5qoreCKtB7uSOsw2h9ld26BSTurzfAgNTbBJrT5cm
Unseal Key 2: 3ybUKOB+7m+11vBMIjIFhGsOxO377r4Q8tHqC98tNTME
Unseal Key 3: Nc8frrPpRRmwZy7j/mFJVCWtilAcXrX6q/PQ21tb5gUU
Unseal Key 4: FZoyx8aZnfs9sydCec4MTuvSgzpM144RzqVWKrdtsjBt
Unseal Key 5: 5NEDaTZ50347RY+Fkhrm45lRcGvEdGheqM9fkTl0Om97
 
Initial Root Token: s.KCMCulHvDKoqqQ5aRwP0tdie
 
Vault initialized with 5 key shares and a key threshold of 3. Please securely
distribute the key shares printed above. When the Vault is re-sealed,
restarted, or stopped, you must supply at least 3 of these keys to unseal it
before it can start servicing requests.
 
Vault does not store the generated master key. Without at least 3 key to
reconstruct the master key, Vault will remain permanently sealed!
 
It is possible to generate new unseal keys, provided you have a quorum of
existing unseal keys shares. See "vault operator rekey" for more information.

Lancer la découverte du premier nœud : “vault01.oowy.lan”

[root@vault001 ~]# vault operator unseal <unseal_key_1>
 
[root@vault001 ~]# vault operator unseal <unseal_key_2>
 
[root@vault001 ~]# vault operator unseal <unseal_key_3>
Key                    Value
---                    -----
Seal Type              shamir
Initialized            true
Sealed                 false
Total Shares           5
Threshold              3
Version                1.4.3
Cluster Name           vault-cluster-c8d63045
Cluster ID             1426c412-5da3-255f-9e10-fe79e39e5b27
HA Enabled             true
HA Cluster             n/a
HA Mode                standby
Active Node Address    <none>

On vérifie l'état de vault

[root@vault001 ~]# vault status
Key             Value
---             -----
Seal Type       shamir
Initialized     true
Sealed          false
Total Shares    5
Threshold       3
Version         1.4.3
Cluster Name    vault-cluster-c8d63045
Cluster ID      1426c412-5da3-255f-9e10-fe79e39e5b27
HA Enabled      true
HA Cluster      https://192.168.1.81:8201
HA Mode         active

Lancer la découverte du second nœud : “vault02.oowy.lan”

[root@vault002 ~]# vault operator unseal <unseal_key_1>
 
[root@vault002 ~]# vault operator unseal <unseal_key_2>
 
[root@vault002 ~]# vault operator unseal <unseal_key_3>
Key                    Value
---                    -----
Seal Type              shamir
Initialized            true
Sealed                 false
Total Shares           5
Threshold              3
Version                1.4.3
Cluster Name           vault-cluster-c8d63045
Cluster ID             1426c412-5da3-255f-9e10-fe79e39e5b27
HA Enabled             true
HA Cluster             n/a
HA Mode                standby
Active Node Address    <none>

On vérifie l'état de vault

[root@vault002 ~]# vault status
Key                    Value
---                    -----
Seal Type              shamir
Initialized            true
Sealed                 false
Total Shares           5
Threshold              3
Version                1.4.3
Cluster Name           vault-cluster-c8d63045
Cluster ID             1426c412-5da3-255f-9e10-fe79e39e5b27
HA Enabled             true
HA Cluster             https://192.168.1.81:8201
HA Mode                standby
Active Node Address    http://192.168.1.81:8200

Se rendre à l'adresse : http://192.168.1.81:8200/ui/

Tester de l'API HTTP en utilisant “curl” pour vérifier l'état d'initialisation.

[root@vault01 ~]# curl http://127.0.0.1:8200/v1/sys/init
{"initialized":true}

Vault est composé de modules. Ces modules permettent de gérer des types de secrets (SSH, PKI, Clé/valeur), des types de stockage (Filesytem, Consul), des systèmes d’identification tiers (LDAP, Kubernetes) et des journaux (syslog, file).

Ils peuvent être classés en 4 familles :

Gestion des secrets
Stockage
Gestion de l'authentification au serveur Vault
Audit

Pour accéder au serveur Vault, on peut utiliser différentes méthodes d’authentification : elles peuvent être internes (user/password, Token) ou externes (LDAP, Radius, Kubernetes).

Voici une capture d’écran des différentes méthodes d'authentification possibles :

La documentation officielle propose plusieurs cas d’utilisation :

AppRole (module à destination des applications et des workflows automatiques)
AWS

Concernant la gestion des secrets, Vault propose une quinzaine de modules. Chaque module gère un type de secret. Par exemple, nous avons le module KV pour les clés/valeurs, ou encore le module AWS pour les access key d’IAM (service de gestion d’identité d’AWS). Voici un screenshot des modules disponibles via l’interface WEB.

A chaque module activé correspond une branche sur l’arbre des données de Vault. Le nom de la branche est choisi par l’utilisateur et plusieurs branches peuvent utiliser le même moteur de secret comme montré dans la copie d’écran suivante :

Selon les modules utilisés, les secrets peuvent être associés à un Time to live (TTL). Ce TTL correspond à une durée de vie du secret. A l’expiration de ce compteur, Vault peut être amené à exécuter des actions selon le type du secret. Par exemple, avec le module MySQL, Vault génère des comptes d’accès aux bases de données et les supprime à la fin de leur TTL.

Vault propose un peu moins de 20 supports de stockage concernant les données. Il existe par exemple des modules de stockage pour S3, etcd et DynamoDB. Quel que soit le module utilisé, les données de Vault sont systématiquement stockées chiffrées.

Tous les modules de stockage proposés ne sont pas supportés directement par Hashicorp. Hashicorp supporte uniquement les modules consul, filsesystem, in-memory (non recommandé pour la production). De plus, la haute disponibilité n’est pas supportée par tous les modules de stockage.

Le choix dépend principalement de votre usage et de vos objectifs. Personnellement, je ne peux que vous conseiller d’utiliser les modules directement supportés par Hashicorp.

Vault nous permet d’obtenir des logs sur tous les appels d’API selon le module d’audit activé via du:

File: en ajoutant les journaux d’audit dans un fichier. Il s’agit d’un dispositif d’audit très simple.
Syslog: en écrivant les journaux d’audit dans syslog.
Socket: où les journaux d’audit sont écrits sur un socket TCP, UDP ou UNIX.

Ces modules d’audit sont des composants Vault qui conservent un journal détaillé de toutes les appels d’API à Vault. Étant donné que chaque opération avec Vault est une demande/réponse d’API, le journal d’audit contient toutes les interactions authentifiées avec Vault, y compris les erreurs.

Exporter votre token Vault root :

export VAULT_TOKEN="s.KCMCulHvDKoqqQ5aRwP0tdie"

Activez ensuite la méthode d'authentification appropriée qui permet aux machines ou aux applications de s'authentifier avec des rôles définis par Vault.

[root@vault01 ~]# vault auth enable approle
Success! Enabled approle auth method at: approle/

La même commande peut être utilisée pour d'autres méthodes d'authentification, par exemple:

[root@vault01 ~]# vault auth enable userpass
Success! Enabled userpass auth method at: userpass/
 
[root@vault01 ~]# vault auth enable ldap
 Success! Enabled ldap auth method at: ldap/

Listez toutes les méthodes d'authentification utilisant la commande :

[root@vault01 ~]# vault auth list
Path         Type        Accessor                  Description
----         ----        --------                  -----------
approle/     approle     auth_approle_8e5b1b54     n/a
token/       token       auth_token_9a9361b6       token based credentials
userpass/    userpass    auth_userpass_3db9acad    n/a

La méthode d'authentification Approle permet aux machines ou aux applications de s'authentifier avec des rôles définis par Vault. La conception ouverte d'AppRole permet un ensemble varié de flux de travail et de configurations pour traiter un grand nombre d'applications.

Cette méthode d'authentification est orientée vers les flux de travail automatisés (machines et services), et est moins utile pour les opérateurs humains.

Un “AppRole” représente un ensemble de politiques et de contraintes de connexion qui doivent être respectées pour recevoir un jeton. Le champ d'application peut être aussi étroit ou aussi large que souhaité. Un AppRole peut être créé pour une machine particulière, ou même un utilisateur particulier sur cette machine, ou un service réparti sur plusieurs machines.

Les informations d'identification requises pour une connexion réussie dépendent des contraintes imposées à l'AppRole associée aux informations d'identification.

La méthode d'authentification “userpass” permet aux utilisateurs de s'authentifier auprès de Vault en utilisant une combinaison : nom d'utilisateur/mot de passe.

Les combinaisons nom d'utilisateur/mot de passe sont configurées directement à la méthode d'authentification en utilisant le chemin users/. Cette méthode ne peut pas lire les noms d'utilisateur et les mots de passe provenant d'une source externe.

La méthode met en minuscules tous les noms d'utilisateur soumis, par exemple Mary et mary sont la même entrée.

La méthode ldap auth permet l'authentification en utilisant un serveur LDAP existant et des identifiants utilisateur/mot de passe. Cela permet d'intégrer Vault dans des environnements utilisant LDAP sans dupliquer la configuration utilisateur/mot de passe à plusieurs endroits.

Il appartient à l'administrateur de fournir des DN correctement échappés. Cela inclut le DN utilisateur, le Bind DN pour la recherche, etc.

En outre, Active Directory a des règles d'échappement qui diffèrent légèrement de la RFC ; en particulier, il exige l'échappement de “#” quelle que soit la position dans le DN (la RFC exige qu'il soit échappé uniquement lorsqu'il s'agit du premier caractère), et “=”, qui, selon la RFC, peut être échappé avec une barre oblique inversée, mais ne contient pas dans son ensemble d'échappements requis.

Si vous utilisez Active Directory et que ces caractères apparaissent dans vos noms d'utilisateur, veuillez vous assurer qu'ils sont échappés, en plus d'être correctement échappés dans vos DN configurés.

Connection parameters

url (string, required) - The LDAP server to connect to. Examples: ldap://ldap.myorg.com, ldaps://ldap.myorg.com:636. This can also be a comma-delineated list of URLs, e.g. ldap://ldap.myorg.com,ldaps://ldap.myorg.com:636, in which case the servers will be tried in-order if there are errors during the connection process.
starttls (bool, optional) - If true, issues a StartTLS command after establishing an unencrypted connection.
insecure_tls - (bool, optional) - If true, skips LDAP server SSL certificate verification - insecure, use with caution!
certificate - (string, optional) - CA certificate to use when verifying LDAP server certificate, must be x509 PEM encoded.
client_tls_cert - (string, optional) - Client certificate to provide to the LDAP server, must be x509 PEM encoded.
client_tls_key - (string, optional) - Client certificate key to provide to the LDAP server, must be x509 PEM encoded.

Binding parameters

There are two alternate methods of resolving the user object used to authenticate the end user: Search or User Principal Name. When using Search, the bind can be either anonymous or authenticated. User Principal Name is a method of specifying users supported by Active Directory. More information on UPN can be found here. »Binding - Authenticated Search

binddn (string, optional) - Distinguished name of object to bind when performing user and group search. Example: cn=vault,ou=Users,dc=example,dc=com
bindpass (string, optional) - Password to use along with binddn when performing user search.
userdn (string, optional) - Base DN under which to perform user search. Example: ou=Users,dc=example,dc=com
userattr (string, optional) - Attribute on user attribute object matching the username passed when authenticating. Examples: sAMAccountName, cn, uid

Les politiques (Policies) Vault contrôlent ce à quoi un utilisateur peut accéder.

Pour l'authentification, Vault dispose de plusieurs options ou méthodes qui peuvent être activées et utilisées. Celui-ci utilise toujours le même format pour l'autorisation et les politiques. Toutes les méthodes d'autorisation renvoient les identités aux politiques de base qui sont configurées avec Vault.

Les politiques sont rédigées en HCL, mais sont compatibles avec JSON. Voici un exemple de politique :

# Dev servers have version 2 of KV secrets engine mounted by default, so will
# need these paths to grant permissions:
path "secret/data/*" {
  capabilities = ["create", "update"]
}
 
path "secret/data/foo" {
  capabilities = ["read"]
}

Grâce à cette politique, un utilisateur peut écrire n'importe quel secret dans secret/data/, sauf dans secret/data/foo, où seul l'accès en lecture est autorisé.

Note:

Par défaut, la politique est de refuser, donc tout accès à un chemin non spécifié n'est pas autorisé.

Le format de la politique utilise un système de correspondance de préfixes sur le chemin de l'API pour déterminer le contrôle d'accès. La politique définie la plus spécifique est utilisée, soit une correspondance exacte, soit la correspondance du préfixe le plus long. Comme tout ce qui se trouve dans Vault doit être accessible via l'API, cela permet un contrôle strict de chaque aspect de Vault, y compris l'activation des moteurs de secrets, l'activation des méthodes d'authentification, l'authentification, ainsi que l'accès secret.

Certaines politiques intégrées ne peuvent pas être supprimées.

Par exemple, les politiques root et default sont des politiques obligatoires et ne peuvent pas être supprimées.

La politique default fournit un ensemble commun de permissions et est incluse par défaut sur tous les jetons.
La politique root donne à un jeton les autorisations de super-administrateur, comme un utilisateur root sur une machine linux.

Pour visualiser la politique par défaut.

$ vault policy read default

Pour rédiger une politique, utilisez la commande vault policy write. Consultez l'aide à la commande.

$ vault policy write -h
 
Usage: vault policy write [options] NAME PATH
 
  Uploads a policy with name NAME from the contents of a local file PATH or
  stdin. If PATH is "-", the policy is read from stdin. Otherwise, it is
  loaded from the file at the given path on the local disk.
 
  Upload a policy named "my-policy" from "/tmp/policy.hcl" on the local disk:
 
      $ vault policy write my-policy /tmp/policy.hcl
 
  Upload a policy from stdin:
 
      $ cat my-policy.hcl | vault policy write my-policy -
 
   ...snip...

Créer la politique appelée my-policy avec le contenu suivant.

$ vault policy write my-policy - << EOF
# Dev servers have version 2 of KV secrets engine mounted by default, so will
# need these paths to grant permissions:
path "secret/data/*" {
  capabilities = ["create", "update"]
}
 
path "secret/data/foo" {
  capabilities = ["read"]
}
EOF

Listez toutes les politiques.

$ vault policy list
 
default
my-policy
root

Voir le contenu de la politique “my-policy”.

$ vault policy read my-policy
 
# Dev servers have version 2 of KV secrets engine mounted by default, so will
# need these paths to grant permissions:
path "secret/data/*" {
  capabilities = ["create", "update"]
}
 
path "secret/data/foo" {
  capabilities = ["read"]
}

La politique créée prévoit une gestion limitée des secrets définis pour le moteur de secrets KV-V2. Les politiques sont attachées à des jetons que Vault génère directement ou par ses différentes méthodes d'authentification.

Créez un jeton et ajoutez la politique my-policy.

$ vault token create -policy=my-policy
 
Key                  Value
---                  -----
token                s.P042DI1d3nOOmJK50vhSnQwc
token_accessor       2yRS09LlxlokNih6JtR9WkRk
token_duration       10h
token_renewable      true
token_policies       ["default" "my-policy"]
identity_policies    []
policies             ["default" "my-policy"]

Copiez la valeur du jeton généré.

La politique permet de créer et de mettre à jour les capacités pour chaque chemin d'accès au sein du moteur secret, sauf un.

Écrivez un secret dans le chemin secret/data/creds.

[root@vault01 ~]# VAULT_TOKEN=s.P042DI1d3nOOmJK50vhSnQwc vault kv put secret/creds password="my-long-password"
 
Key              Value
---              -----
created_time     2020-12-09T20:21:17.688551247Z
deletion_time    n/a
destroyed        false
version          1

Le secret est créé avec succès.

La politique n'autorise la lecture que pour le chemin du secret, des données et des fichiers. Une tentative d'écriture sur ce chemin entraîne une erreur “permission refusée”.

Tentative d'écriture dans le chemin secret/data/foo.

[root@vault01 ~]# VAULT_TOKEN=s.P042DI1d3nOOmJK50vhSnQwc vault kv put secret/foo robot=beepboop
Error writing data to secret/data/foo: Error making API request.
 
URL: PUT http://127.0.0.1:8200/v1/secret/data/foo
Code: 403. Errors:
 
* 1 error occurred:
	* permission denied

L'erreur de permission est affichée.

Cette politique définit un ensemble limité de chemins et de capacités. Sans accès à sys, les commandes telles que vault policy list ou vault secrets list ne fonctionneront pas.

Vault est l'unique autorité politique, contrairement à l'authentification où vous pouvez activer plusieurs méthodes.

Vous pouvez configurer les Auth Methodes pour assigner automatiquement un ensemble de stratégies aux jetons créés en vous authentifiant avec. La façon dont cela se fait diffère selon la méthode d’autorisation connexe, mais implique généralement de mapper un rôle à des politiques ou de mapper des identités ou des groupes à des politiques.

Par exemple, vous pouvez y parvenir avec le paramètre token_policies lors de la configuration d'un rôle pour la méthode d'authentification AppRole.

Pour accéder à l'explorateur API, ouvrez le CLI du navigateur en choisissant l'icône du terminal comme indiqué dans la capture d'écran de navigation.

Le CLI s'ouvrira pour révéler un > prompt. Tapez help à tout moment pour obtenir de l'aide pour l'utiliser.

Accédez à l'explorateur API en tapant api à l'invite et en appuyant sur entrer.

Un avertissement est émis pour le premier accès à l'API, vous devez le lire et le comprendre attentivement avant de lancer des requêtes, en particulier lorsque vous utilisez un jeton hautement privilégié.

Attention:

The “Try it out” functionality in this API explorer will make requests to this Vault server on your behalf. IF YOUR TOKEN HAS THE PROPER CAPABILITIES, THIS WILL CREATE AND DELETE ITEMS ON THE VAULT SERVER. Your token will also be shown on the screen in the example curl command output.

Nous allons mettre devant nos serveur Vault un système de load balancing.

Celui-ci va dispatcher les flux entrant vers le premier server Vault. En cas de non disponibilitée, les flux seront transférés vers le serveur Vault secondaire qui se chargera ensuite de traiter la demande.

Vue fonctionnelle :

user → WWW → Loadbalancer (haproxy) → Vault Server

Pour cela il faut faudra un server portant le service “haproxy”

Un fois connecté sur le serveur répliquer la configuration haproxy qui suit :

Note:

Les informations correspondant à Vault sont vault_cluster_frontend et vault_cluster_backend

[root@proxy ~]# cat /etc/haproxy/haproxy.cfg
#---------------------------------------------------------------------
# Example configuration for a possible web application.  See the
# full configuration options online.
#
#   http://haproxy.1wt.eu/download/1.4/doc/configuration.txt
#
#---------------------------------------------------------------------
 
#---------------------------------------------------------------------
# Global settings
#---------------------------------------------------------------------
global
    # to have these messages end up in /var/log/haproxy.log you will
    # need to:
    #
    # 1) configure syslog to accept network log events.  This is done
    #    by adding the '-r' option to the SYSLOGD_OPTIONS in
    #    /etc/sysconfig/syslog
    #
    # 2) configure local2 events to go to the /var/log/haproxy.log
    #   file. A line like the following can be added to
    #   /etc/sysconfig/syslog
    #
    #    local2.*                       /var/log/haproxy.log
    #
    log         127.0.0.1 local2
 
    chroot      /var/lib/haproxy
    pidfile     /var/run/haproxy.pid
    maxconn     4000
    user        haproxy
    group       haproxy
    daemon
 
    # turn on stats unix socket
    stats socket /var/lib/haproxy/stats
 
#---------------------------------------------------------------------
# common defaults that all the 'listen' and 'backend' sections will
# use if not designated in their block
#---------------------------------------------------------------------
defaults
    mode                    http
    log                     global
    option                  httplog
    option                  dontlognull
    option http-server-close
    option forwardfor       except 127.0.0.0/8
    option                  redispatch
    retries                 3
    timeout http-request    10s
    timeout queue           1m
    timeout connect         10s
    timeout client          1m
    timeout server          1m
    timeout http-keep-alive 10s
    timeout check           10s
    maxconn                 3000
 
# Load Balancing statistics for HAProxy
frontend stats-front
        bind *:8282
        mode http
        default_backend stats-back
 
backend stats-back
        mode http
        option httpchk
        balance roundrobin
        stats uri /
        stats auth admin:secret
        stats refresh 10s
#
# Hashicorp Vault
#
frontend vault_cluster_frontend
     bind 0.0.0.0:8200
     mode http
     option tcplog
     default_backend vault_cluster_backend
 
backend vault_cluster_backend
     mode http
     option httpchk GET /v1/sys/health
     balance roundrobin
     server vault1 vault01.oowy.lan:8200 check
     server vault2 vault02.oowy.lan:8200 check

Vous pourrez vérifier la configuration de “haproxy” avec la commande qui suit :

[root@proxy ~]# haproxy -c -V -f /etc/haproxy/haproxy.cfg
Configuration file is valid

La procédure de mise à niveau recommandée, et celle utilise en interne à HashiCorp.

Toutefois, vous devez réfléchir à la manière d'appliquer ces étapes à votre configuration particulière, car les configurations HA peuvent différer selon qu'un équilibreur de charge est utilisé, les adresses données aux clients pour se connecter à Valut (standby + leader, leader-only, ou découvert via la découverte de service), etc.

Quelle que soit la méthode utilisée, vous devez veiller à ne jamais rétrograder une version récente de Vault à une version plus ancienne. La procédure que nous proposons vise à éviter cela.

Veuillez noter que Vault ne prend pas en charge les véritables mises à niveau sans interruption de service, mais avec une procédure de mise à niveau appropriée, le temps d'arrêt devrait être très court (quelques centaines de millisecondes à une seconde selon la vitesse d'accès au backend de stockage).

Effectuez ces étapes à chaque mise en veille :

Arrêter correctement Vault sur le nœud de secours
Remplacer le binaire Vault par la nouvelle version
Démarrer le nœud de secours
Déverrouiller le nœud de secours

À ce stade, tous les nœuds de secours seront mis à niveau et prêts à prendre la relève. La mise à niveau ne sera pas achevée tant que l'un des nœuds de secours mis à niveau n'aura pas pris le relais. Pour ce faire :

Fermez correctement le nœud restant (actif).

Note:

Note : il est très important d’arrêter correctement le nœud. Le verrouillage des HA est alors libéré, ce qui permet à un nœud en attente de prendre le relais avec un délai très court. Si vous tuez Vault sans la laisser libérer le verrouillage, un nœud de secours ne pourra pas prendre le relais avant l'expiration de la période de temporisation du verrouillage. Ce délai est spécifique à la backend mais peut être de dix secondes ou plus.

Remplacez le binaire de Vault par la nouvelle version ; assurez-vous que la capacité mlock() est ajoutée au nouveau binaire avec setcap.

Démarrer le nœud

Déverrouillez le nœud (il sera alors en attente)

Les tâches de mise à niveau interne auront lieu après que l'un des nœuds de veille mis à niveau aura pris le relais du service actif.

Storage Backend - Un backend de stockage est responsable du stockage durable des données cryptées. Les backends n'ont pas la confiance de Vault et ne sont censés assurer que la durabilité. Le backend de stockage est configuré au démarrage du serveur Vault.
Barrier - est constituée de clé de chiffrement concret autour de Vault. Toutes les données qui circulent entre Vault et le backend de stockage passent à travers Barrier. Barriere garantit que seules des données cryptées sont écrites, et que les données sont vérifiées et décryptées à l'entrée. Tout comme une chambre forte de banque, la barrière doit être “descellée” avant que l'on puisse accéder à tout ce qui se trouve à l'intérieur.
Secrets Engine - Un moteur des secrets est responsable de la gestion des secrets. De simples moteurs à secrets comme le moteur à secrets “kv” renvoient simplement le même secret lorsqu'ils sont interrogés. Certains moteurs de secrets permettent d'utiliser des politiques pour générer dynamiquement un secret chaque fois qu'ils sont interrogés. Cela permet d'utiliser des secrets uniques, ce qui permet à Vault d'effectuer des révocations et des mises à jour de politiques à grain fin. Par exemple, un moteur de secrets MySQL pourrait être configuré avec une politique “web”. Lorsque le secret “web” est lu, un nouveau couple utilisateur/mot de passe MySQL sera généré avec un ensemble limité de privilèges pour le serveur web.
Audit Device - Un dispositif d'audit est responsable de la gestion des journaux d'audit. Chaque demande adressée à Vault et chaque réponse de Vault passe par les dispositifs d'audit configurés.
Auth Method - Une méthode d'authentification est utilisée pour authentifier les utilisateurs ou les applications qui se connectent à Vault. Une fois authentifiée, la méthode d'authentification renvoie la liste des politiques applicables qui doivent être appliquées. Vault prend un utilisateur authentifié et renvoie un jeton client qui peut être utilisé pour des demandes futures. Par exemple, la méthode d'authentification “userpass” utilise un nom d'utilisateur et un mot de passe pour authentifier l'utilisateur. La méthode d'authentification github permet également aux utilisateurs de s'authentifier via GitHub.
Client Token - Un jeton client (alias “Vault Token”) est conceptuellement similaire à un cookie de session sur un site web. Une fois qu'un utilisateur s'est authentifié, Vault renvoie un jeton client qui est utilisé pour les demandes ultérieures. Le jeton est utilisé par Vault pour vérifier l'identité du client et pour faire appliquer les politiques ACL applicables. Ce jeton est transmis via les en-têtes HTTP.
Secret - Un secret est le terme utilisé pour tout ce qui est renvoyé par Vault et qui contient du matériel confidentiel ou cryptographique. Tout ce qui est renvoyé par Vault n'est pas un secret. Par exemple, la configuration du système, les informations d'état ou les politiques ne sont pas considérées comme des secrets. Les secrets ont toujours un bail associé. Cela signifie que les clients ne peuvent pas supposer que le contenu secret peut être utilisé indéfiniment. Vault révoque un secret à la fin du bail, et un opérateur peut intervenir pour révoquer le secret avant la fin du bail. Ce contrat entre Vault et ses clients est essentiel, car il permet de modifier les clés et les politiques sans intervention manuelle.
Server - Vault dépend d’une instance de longue durée qui fonctionne comme un serveur. Le serveur Vault fournit une API avec laquelle les clients interagissent et gère l’interaction entre tous les moteurs de secrets, l’application ACL, et la révocation de bail secret. Une architecture basée sur le serveur dissocie les clients des clés et des politiques de sécurité, permet la journalisation centralisée des audits et simplifie l’administration pour les opérateurs.

https://www.vaultproject.io/

https://learn.hashicorp.com/vault/getting-started/install

https://www.vaultproject.io/docs/upgrading

https://www.vaultproject.io/docs/concepts/policies

https://learn.hashicorp.com/vault/operations/troubleshooting-vault#audit-logs

https://learn.hashicorp.com/vault/operations/storage-migration-checklist

https://learn.hashicorp.com/vault/operations/ops-reference-architecture

https://learn.hashicorp.com/vault/operations/production-hardening

https://learn.hashicorp.com/collections/vault/getting-started-ui

https://learn.hashicorp.com/tutorials/vault/reference-architecture#load-balancing

#####

https://www.vaultproject.io/docs/internals/integrated-storage

https://learn.hashicorp.com/collections/vault/day-one-raft

https://learn.hashicorp.com/tutorials/vault/raft-reference-architecture?in=vault/day-one-raft

https://learn.hashicorp.com/collections/vault/day-one-consul

https://learn.hashicorp.com/tutorials/vault/reference-architecture?in=vault/day-one-consul

https://learn.hashicorp.com/tutorials/vault/reference-architecture#design-summary

Si le service “firewalld” est activé sur les nœuds, nous devrons ouvrir les flux nécessaires au bon fonctionnement de la solution.

# firewall-cmd --add-port={8200,8201}/tcp --permanent
# firewall-cmd --reload

Introduction

Caractéristiques de Vault

Architecture

Détails sur la connectivité réseaux

Pré-Requis

Consul

Installation

Configuration

Lancement consul

Vault

Installation

Configuration

Initialisation de Vault

Premier nœud vault

Second nœud vault

Accès WEB UI

Test API

Administration

Les Modules

Gestion de l'authentification

Gestion des secrets

Stockage

Audit

Activation méthode d'authentification

Auth Methodes - Approle

Auth Methodes - Userpass

Auth Methodes - Active Directory

Connection parameters

Binding parameters

Policies

Format des Policies

Rédiger une politique

Tester la politique

Associer les Policies aux Auth Methodes

Gestion des secrets

Vault API

Load balancing worker nodes

Update plateforme

Glossaire

Annexe

Firewall