Table des matières

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.

Caractéristiques de Vault

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

Architecture

Détails sur la connectivité réseaux

Pré-Requis

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

Nommage et IP :

Stockage :

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

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.

Consul

Installation

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)

Configuration

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!

Lancement consul

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>

Vault

Installation

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

Configuration

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"

On rend active le service au démarrage. 

# systemctl enable vault

On démarre vault. 

# systemctl start vault

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

Premier nœud vault

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

Second nœud vault

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

Accès WEB UI

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

Test API

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}

Administration

Les Modules

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 de l'authentification

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 :

Gestion des secrets

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.

Stockage

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.

Audit

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

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.

Activation méthode d'authentification

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

Auth Methodes - Approle

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.

Auth Methodes - Userpass

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.

Auth Methodes - Active Directory

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

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

Policies

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.

Format des Policies

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.

Pour visualiser la politique par défaut. 

$ vault policy read default

Rédiger une politique

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

Tester la politique

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.

Associer les Policies aux Auth Methodes

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.

Gestion des secrets

Vault API

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.

Load balancing worker nodes

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

Update plateforme

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 :

À 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 :

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.

Glossaire

Annexe

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

Firewall

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