Description

Vault sécurise, stocke et contrôle étroitement l'accès aux jetons, aux mots de passe, aux certificats, aux clés API et aux autres secrets de l'informatique moderne.

Il est hautement disponible car il est hébergé sur trois VM, chacune d'entre elles se trouvant dans une zone de disponibilité différente.

Architecture

Topologies

Résilience

Répartition des nœuds par zone de disponibilité :

Fonctionnalités

Cette section liste les fonctionnalités disponibles pour le client, ainsi que la manière de les demander ou de les exécuter :

Ressources

Chacun des trois nœuds possède les caractéristiques matérielles suivantes : 2 CPU, 4 Go de RAM et 90 Go de disque SSD.

Diagramme

Sécurité

Authentification

Le PaaS Vault est disponible sur HTTPS en utilisant les comptes d'administration. Cela garantit une authentification centralisée.

Autorisations

Par défaut, il existe deux rôles :

• l'administrateur sécurité, qui dispose d'un accès complet en lecture sur les clusters Vault.

• l'administrateur du cluster, qui peut :

  • Lire le bilan de santé du système

  • Activer et gérer les méthodes d'authentification dans Vault

  • Créer et gérer des politiques ACL dans Vault, sauf sur les politiques cluster_admin et security_admin.

  • Activer et gérer les clés/valeurs des secrets/paths.

  • Activer et gérer le moteur de secrets

  • Gérer les identités

Transport sécurisé

Tout le trafic est envoyé par HTTPS. Aucune donnée n'est envoyée en clair.

Management des logs

Vault dispose de deux types de logs : les logs opérationnels du serveur Vault et les logs d'audit. Les logs d'audit enregistrent chaque demande faite à Vault ainsi que la réponse envoyée par Vault.

Les logs du serveur sont des logs opérationnels qui donnent un aperçu de ce que le serveur fait en interne et en arrière-plan pendant l'exécution de Vault.

Les dispositifs d'audit sont activés et les logs de sortie sont stockés dans le fichier /var/log/vault/vault_audit.log. Les serveurs de Vault reçoivent l'application UF_ALL_IT-vault qui envoie les fichiers de logs à Splunk par syslog, dans l'index vault et applique le sourcetype vault.

Emplacement des données

Les données sont situées dans EB ou ET, en fonction du DC choisi par le client lors de la commande du cluster Vault.

Politiques

Cette section énumère les politiques de gestion :

Un ticket devra être créé pour modifier ces politiques.

Mots de passe

Il n'y a qu'un seul compte intégré en cas d'urgence. C'est le root token et il a tous les droits sur le cluster Vault.

Il est stocké en toute sécurité dans le serveur Vault de transit et toute utilisation du root token déclenche une alerte dans le SIEM.

Surveillance

cegedim.cloud fournit une surveillance de base sur la mémoire, le CPU, le réseau et l'espace disque.

Les surveillances personnalisées suivantes ont été ajoutées dans Centreon :

Description

Vault est destiné à être le référentiel unique de vos secrets, qu'il s'agisse de mots de passe, de jetons, de certificats, de clés publiques/privées, etc.

C'est vers là que vos applications et services se tourneront pour consommer les secrets dont ils ont besoin. Dites adieu aux mots de passe en clair dans vos fichiers de configuration, vos scripts ou votre code source et sécurisez votre pipeline CI/CD !

Vault fournit un chiffrement fort des secrets, une gestion des authentifications et des autorisations. La ressource peut être un utilisateur humain ou une machine.

• Gestion des secrets

  • Centralisation des secrets dans un espace sécurisé et hautement disponible

  • Réduire les risques et respecter les normes de sécurité et les meilleures pratiques : les mots de passe ne sont plus stockés ou affichés en clair.

  • Secrets dynamiques : créer, renouveler et révoquer automatiquement des secrets à la volée.

• Le chiffrement en tant que service

  • Cryptez vos données à la volée sans vous soucier de la gestion des clés de cryptage

  • Mise à jour et rotation faciles des clés de chiffrement

• " API First " : tout peut être contrôlé par API, en plus de l'interface Web

• Gestion granulaire des profils et des droits d'accès

• Traçabilité complète des actions de l'administration et de l'accès aux secrets

Pourquoi Vault ?

Vault a pour but de répondre aux besoins suivants :

• Partage d'informations sensibles de manière sécurisée

• Contrôle d'accès avec possibilité de révoquer l'accès

• Granularité via des politiques permettant de ne partager que certaines données

Il est composé de quatre services principaux :

• Le service Storage (Consul par exemple) est l'endroit où les données persistantes et cryptées de Vault seront stockées.

• Le service Secret permet de stocker des secrets statiques et de générer des secrets dynamiques (pour AWS, Azure ou GCP par exemple).

• Le service Audit vous permet d'enregistrer chaque demande afin de suivre toutes les interactions avec Vault.

• Le service Auth backend gère plusieurs méthodes d'authentification permettant à Vault d'être adaptable à tout type d'utilisation. Par exemple, nous pouvons utiliser la méthode AppRole pour authentifier les applications mais aussi GitHub pour un groupe de développeurs.

Plateforme en tant que Service

Vault est déployé on-premise dans les datacenters de cegedim.cloud.

Le même niveau de service que pour l'offre Compute est garanti : déploiement des instances, maintien en condition opérationnelle, flexibilité, sécurité et monitoring sont ainsi assurés par nos experts.

La topologie disponible est la topologie de cluster prête avec 3 nœuds répartis sur toutes les zones de disponibilité d'une zone cible. La version actuelle supportée est la version 1.8.1.

cegedim.cloud déploie Vault avec auto-unseal pour réduire la complexité opérationnelle du maintien de la sécurité de la clé d'unseal. La clé racine cryptée est stockée dans un Transit Secrets Engine à l'intérieur d'un autre cluster Vault géré exclusivement par cegedim.cloud.

Facturation

Vault est facturé mensuellement par cluster, quel que soit le nombre d'utilisateurs et le nombre de secrets stockés.

Pour connaître les coûts exacts d'un cluster Vault, veuillez contacter votre Service Delivery Manager.

Déployer Vault

Vault peut être déployé via ITCare depuis la section Sécurité du menu latéral gauche.

Un bouton Créer une instance Vault vous permet d'accéder au formulaire de déploiement.

Chercher et sélectionner le Service Global dans lequel vous allez créer votre nouvelle instance Vault. Cliquer sur Suivant.

A l'étape suivante, fournir les informations suivantes :

• Le nom de l'instance de Vault

• Le groupe AD de sécurité pour l'administration

Cliquer sur Suivant, puis sélectionner la Région dans laquelle vous souhaitez effectuer le déploiement.

Enfin, la synthèse de votre demande s'affiche. Vérifier les informations saisies puis soumettre pour lancer la création de votre instance Vault.

Une fois l'instance créée, vous serez notifié par e-mail.

Le CLI Vault sur votre bastion

Cette procédure vous explique comment déployer le CLI Vault sur votre bastion.

Télécharger la dernière version de Vault CLI depuis https://www.vaultproject.io/downloads sur votre poste de travail.

Copier le fichier téléchargé "vault_x.x.x_windows_amd64.zip" sur votre Bastion dans C:\temp.

Ouvrir un cmd shell et exécutez la commande ci-dessous :

mkdir %LOCALAPPDATA%\Vault "C:\Program Files\7-Zip\7z.exe" e c:\temp\vault_x.x.x_windows_amd64.zip "*.*" -o"%LOCALAPPDATA%\Vault"

Intégration Kubernetes

Demande de prérequis Vault sur Kubernetes

Cet article décrit comment demander le prérequis de Vault sur les Services de conteneurs de cegedim.cloud**.**

Après la résolution du ticket, allez dans Rancher Cluster Manager → Cluster → Modifier pour vérifier si l'Authorized EndPoint est activé.

À partir de Rancher Cluster Explorer → Apps & Marketplace, vérifiez si le graphique de la voûte est disponible.

Configurer Vault Injector sur Kubernetes

Cet article décrit comment configurer l'injecteur Vault sur le service Kubernetes fourni par cegedim.cloud**.**

Créer un projet et un espace Vault

• Créer un projet : vault

• Créer un espace : vault

Déployer Vault Agent Injector

• Depuis Rancher, allez dans "Apps & Marketplace" → "Charts".

• Recherchez "vault" et sélectionnez "vault - Official HashiCorp Vault Chart".

• Sélectionnez l'espace "vault" et nommez votre déploiement "vault-injector"

Allez dans "Values YAML" et recherchez le paramètre "externalVaultAddr" pour définir la valeur avec l'URL de votre cluster de vault : https://<cluster>.vault.cegedim.cloud

Cliquez sur Installer.

Étapes de contrôle

Le déploiement sera créé dans l'espace vault :

ClusterRole :

• vault-injector-agent-injector-clusterrole

ServiceAccounts _:_

• vault-injector : ce compte de service sera utilisé par vault pour se connecter à l'API Kubernetes.

• vault-injector-agent-injector : ce compte de service est utilisé par le vault-injector-agent-injector

CusterRoleBindings :

• vault-injector-agent-injector-binding: attache le ClusterRole vault-injector-agent-injector-clusterrole au compte de service vault-injector-agent-injector

• vault-injector-server-binding : fournit system:auth-delegator au compte de service vault-injector

Déploiement :

• vault-injector-agent-injector

Configuration de la méthode d'authentification Kubernetes sur cegedim Vault

Cet article décrit comment activer la méthode auth de kubernetes pour s'authentifier sur l'instance Vault cegedim.cloud en utilisant un jeton de compte de service Kubernetes.

Conditions préalables :

• CLI de Vault

• Point d'accès autorisé de Kubernetes pour Vault

• certificat kubernetes

Activer Méthode d'authentification Kubernetes sur votre cegedim.cloud Services de conteneurs Depuis Vault CLI configuré et connecté à votre cegedim.cloud Vault instance cluster.

vault auth enable -path=kubernetes-<ccs-my-cluster> kubernetes

Vous pouvez vérifier avec l'interface utilisateur de Vault la configuration de cette méthode d'authentification dans l'onglet Accès.

Configurer la méthode Auth de Kubernetes

Conditions préalables :

• jeton_reviewer_jwt: Token à obtenir de Rancher Kubernetes Secret vault-injector-token

• kubernetes_host: Kubernetes Authorized Endpoint API pour obtenir de la configuration de Rancher Kubernetes Cluster.

• kubernetes_ca_cert: Utiliser ci-dessous le certificat racine de l'AC de l'API Kubernetes Authorized Endpoint

Copiez/collez le fichier de certificat ci-dessous sur C:\Temp dans votre profil bastion pour permettre l'accès avec Vault CLI.

• À partir du shell cmd, exécutez la commande ci-dessous avec les valeurs prérequises correctes ci-dessus pour configurer la méthode Auth :

vault write auth/kubernetes-<ccs-my-cluster>/config token_reviewer_jwt="xxxxxxxxxxxxxxxxxx" kubernetes_host="https://<my-ccs-cluster>-api.ccs.cegedim.cloud" kubernetes_ca_cert=@isg_root_x1.cer disable_iss_validation=true

Cas d'usage agents Vault avec Kubernetes

Injecter des secrets dans le chemin du pod /vault/secrets/

Cet article décrit comment déployer la base de données PostgreSQL avec le nom d'utilisateur et le mot de passe stockés dans l'instance Vault.

Conditions préalables :

• Cluster Kubernetes cegedim.cloud

• Instance Vault cegedim.cloud

• CLI de Vault

• Kubernetes connecté à Vault

• Kubectl

Connectez-vous à votre Vault

#Skip vault verification
set VAULT_SKIP_VERIFY=True
 
#Set vault address
set VAULT_ADDR="https://<my-vault-cluster>.vault.cegedim.cloud/"
 
#Get vault status
vault status
 
#Login on vault by selecting ldap method
vault login -method=ldap username="adm-<your-login>"

Créer le moteur demopostgres

#Create Engine on vault
vault secrets enable -path=secret/demopostgres kv-v2

Créez votre nom d'utilisateur et votre mot de passe DB Secret

#Create your secret on vault
vault kv put secret/demopostgres/db username="myusername" password="mysecret"
 
#Check secret
vault kv get secret/demopostgres/db

Créer le fichier de politique de lecture JSON C:\Temp\policy_demopostgres.json

path "secret/demopostgres/data/db"
{
  capabilities = ["read"]
}

Créer une politique

#Create policy
vault policy write policy_demopostgres c:\Temp\policy_demopostgres.json
 
#Check policy creation
vault policy read policy_demopostgres

Appliquer la politique sur le secret

Cette action connecte le compte de service Kubernetes sa-demopostgres, de l'espace de noms vault-demopostgres avec la politique Vault policy_demopostgres.

Le jeton renvoyé après l'authentification est valide pendant 24 heures.

#Apply policy on secret
vault write auth/kubernetes-<ccs-my-cluster>/role/demopostgres bound_service_account_names=sa-demopostgres bound_service_account_namespaces=vault-demopostgres policies=policy_demopostgres ttl=24h

Créer un espace de nom

#Create Namespace
kubectl create namespace vault-demopostgres

Créer un compte de service Kubernetes

#Create Kubernetes Service Account
kubectl create serviceaccount sa-demopostgres --namespace vault-demopostgres
 
# Verify that the service account has been created
kubectl get serviceaccounts --namespace vault-demopostgres

Créer le fichier de déploiement vault_demopostgres.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: db-postgres
  name: db-postgres
spec:
  selector:
    matchLabels:
      app: db-postgres
  replicas: 1
  template:
    metadata:
      labels:
        app: db-postgres
      annotations:
        vault.hashicorp.com/agent-inject: "true"
        vault.hashicorp.com/role: "demopostgres"
        vault.hashicorp.com/agent-inject-status: "update"
        vault.hashicorp.com/agent-cache-enable: "true"
        vault.hashicorp.com/auth-path: auth/kubernetes-ccs2-rd-shared
        vault.hashicorp.com/agent-inject-secret-db-username: secret/demopostgres/db
        vault.hashicorp.com/agent-inject-template-db-username: |
          {{ with secret "secret/demopostgres/db" -}}
          {{ .Data.data.username }}
          {{- end }}
        vault.hashicorp.com/agent-inject-secret-db-password: secret/demopostgres/db
        vault.hashicorp.com/agent-inject-template-db-password: |
          {{ with secret "secret/demopostgres/db" -}}
          {{ .Data.data.password }}
          {{- end }}
    spec:
      serviceAccountName: sa-demopostgres
      containers:
      - name: db-postgres
        image: postgres
        imagePullPolicy: "IfNotPresent"
        env:
        - name: POSTGRES_USER_FILE
          value: /vault/secrets/db-username
        - name: POSTGRES_PASSWORD_FILE
          value: /vault/secrets/db-password
        - name: POSTGRES_HOST_AUTH_METHOD
          value: "scram-sha-256"
        - name: POSTGRES_INITDB_ARGS
          value: --auth-host=scram-sha-256
        ports:
        - containerPort: 5432
        resources:
          requests:
            memory: "200Mi"
            cpu: "100m"
          limits:
            memory: "1Gi"
            cpu: "500m"
        volumeMounts:
        - mountPath: /var/lib/postgresql/data
          name: postgresql-data
      volumes:
      - name: postgresql-data
        emptyDir: {}
---
apiVersion: v1
kind: Service
metadata:
  name: db-postgres
spec:
  selector:
    app: db-postgres
  ports:
  - protocol: TCP
    port: 5432

Déploiement de Vault Postgres Demo

kubectl apply -f vault_demopostgres.yaml --namespace vault-demopostgres

Étapes de contrôle

• Vérifiez votre déploiement dans Rancher

Injecter des Secrets dans un pod avec Configmap

Cet article décrit comment déployer SonarQube une application avec une base de données PostgreSQL dont le nom d'utilisateur et le mot de passe sont stockés dans l'instance Vault de cegedim.cloud.

Conditions préalables :

• Cluster Kubernetes cegedim.cloud

• Instance Vault cegedim.cloud

• CLI de Vault

• Kubernetes connecté à Vault

• Kubectl

Connectez-vous à votre Vault

#Skip vault verification
set VAULT_SKIP_VERIFY=True
 
#Set vault address
set VAULT_ADDR="https://<my-vault-cluster>.vault.cegedim.cloud/"
 
#Get vault status
vault status
 
#Login on vault by selecting ldap method
vault login -method=ldap username="adm-<your-login>"

Créer le moteur demopostgres

#Create Engine on vault
vault secrets enable -path=secret/demopostgres kv-v2

Créez votre nom d'utilisateur et votre mot de passe DB Secret (ou réutiliser le DB Secret créé précédemment)

#Create your secret on vault
vault kv put secret/demopostgres/db username="myusername" password="mysecret"
 
#Check secret
vault kv get secret/demopostgres/db

Créer le fichier de politique de lecture JSON C:\Temp\policy_demopostgres.json

path "secret/demopostgres/data/db" { capabilities = ["read"] }

Créer une politique

#Create policy
vault policy write policy_demopostgres c:\Temp\policy_demopostgres.json
 
#Check policy creation
vault policy read policy_demopostgres

Appliquer la politique sur le secret

Cette action connecte le compte de service Kubernetes sa-demopostgres, de l'espace de noms vault-demopostgres avec la politique Vault policy_demopostgres.

Le jeton renvoyé après l'authentification est valide pendant 24 heures.

#Apply policy on secret
vault write auth/kubernetes-<ccs-my-cluster>/role/demopostgres bound_service_account_names=sa-demopostgres bound_service_account_namespaces=vault-demopostgres policies=policy_demopostgres ttl=24h

Créer un espace de nom (ou réutiliser un Namespace créé précédemment)

#Create Namespace
kubectl create namespace vault-demopostgres

Créer un compte de service Kubernetes (ou réutiliser le compte de service créé précédemment)

#Create Kubernetes Service Account
kubectl create serviceaccount sa-demopostgres --namespace vault-demopostgres
 
# Verify that the service account has been created
kubectl get serviceaccounts --namespace vault-demopostgres

Créer le fichier de déploiement vault_demosonarqube.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: db-sonarqube
  name: db-sonarqube
spec:
  selector:
    matchLabels:
      app: db-sonarqube
  replicas: 1
  template:
    metadata:
      labels:
        app: db-sonarqube
      annotations:
        vault.hashicorp.com/agent-inject: "true"
        vault.hashicorp.com/role: "demopostgres"
        vault.hashicorp.com/agent-inject-status: "update"
        vault.hashicorp.com/agent-cache-enable: "true"
        vault.hashicorp.com/auth-path: auth/kubernetes-ccs2-rd-shared
        vault.hashicorp.com/agent-inject-secret-db-username: secret/demopostgres/db
        vault.hashicorp.com/agent-inject-template-db-username: |
          {{ with secret "secret/demopostgres/db" -}}
          {{ .Data.data.username }}
          {{- end }}
        vault.hashicorp.com/agent-inject-secret-db-password: secret/demopostgres/db
        vault.hashicorp.com/agent-inject-template-db-password: |
          {{ with secret "secret/demopostgres/db" -}}
          {{ .Data.data.password }}
          {{- end }}
    spec:
      serviceAccountName: sa-demopostgres
      containers:
      - name: db-sonarqube
        image: postgres
        imagePullPolicy: "IfNotPresent"
        env:
        - name: POSTGRES_USER_FILE
          value: /vault/secrets/db-username
        - name: POSTGRES_PASSWORD_FILE
          value: /vault/secrets/db-password
        - name: POSTGRES_HOST_AUTH_METHOD
          value: "scram-sha-256"
        - name: POSTGRES_INITDB_ARGS
          value: --auth-host=scram-sha-256
        ports:
        - containerPort: 5432
        resources:
          requests:
            memory: "200Mi"
            cpu: "100m"
          limits:
            memory: "1Gi"
            cpu: "500m"
        volumeMounts:
        - mountPath: /var/lib/postgresql/data
          name: postgresql-data
      volumes:
      - name: postgresql-data
        emptyDir: {}
---
apiVersion: v1
kind: Service
metadata:
  name: db-sonarqube
spec:
  selector:
    app: db-sonarqube
  ports:
  - protocol: TCP
    port: 5432
---
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: app-sonarqube
  name: app-sonarqube
spec:
  selector:
    matchLabels:
      app: app-sonarqube
  replicas: 1
  template:
    metadata:
      annotations:
        vault.hashicorp.com/agent-inject: "true"
        vault.hashicorp.com/role: "demopostgres"
        vault.hashicorp.com/agent-inject-status: "update"
        vault.hashicorp.com/agent-cache-enable: "true"
        vault.hashicorp.com/agent-cache-use-auto-auth-token: "force"
        vault.hashicorp.com/auth-path: auth/kubernetes-ccs2-rd-shared
        vault.hashicorp.com/agent-inject-secret-sonar.properties: secret/demopostgres/db
        vault.hashicorp.com/secret-volume-path-sonar.properties: "/opt/sonarqube/conf/"
        vault.hashicorp.com/agent-inject-file-sonar.properties: "sonar.properties"
        vault.hashicorp.com/agent-inject-template-file-sonar.properties: /tmp/sonar.properties.tmpl
        vault.hashicorp.com/agent-copy-volume-mounts: app-sonarqube
      labels:
        app: app-sonarqube
    spec:
      serviceAccountName: sa-demopostgres
      containers:
        - name: app-sonarqube
          image: sonarqube:lts-community
          imagePullPolicy: "IfNotPresent"
          resources:
            requests:
              memory: "1200Mi"
              cpu: "100m"
            limits:
              memory: "2500Mi"
              cpu: "500m"
          volumeMounts:
          - mountPath: /opt/sonarqube/data/
            name: sonar-data
          - mountPath: /opt/sonarqube/extensions/
            name: sonar-extensions
          - mountPath: /opt/sonarqube/logs
            name: sonar-logs
          - mountPath: /opt/sonarqube/temp
            name: sonar-temp
          - name: properties
            mountPath: /tmp/sonar.properties.tmpl
            subPath: sonar.properties.tmpl
          ports:
          - containerPort: 9000
            protocol: TCP
      volumes:
      - name: sonar-data
        emptyDir: {}
      - name: sonar-extensions
        emptyDir: {}
      - name: sonar-logs
        emptyDir: {}
      - name: sonar-temp
        emptyDir: {}
      - name: properties
        configMap:
          name: app-sonarqube
---
apiVersion: v1
kind: ConfigMap
metadata:
  name: app-sonarqube
data:
  sonar.properties.tmpl: |
    {{- with secret "secret/demopostgres/db" -}}
    ldap.url: {{ .Data.data.url }}
    ldap.bindDn: CN=sa_rd_automation,OU=Service Accounts,OU=Cegedim R&D,OU=BOU,OU=FR,OU=EMEA,DC=emea,DC=cegedim,DC=grp
    ldap.bindPassword: {{.Data.data.binddn }}
    ldap.group.baseDn: OU=EMEA,DC=emea,DC=cegedim,DC=grp
    ldap.user.baseDn: OU=EMEA,DC=emea,DC=cegedim,DC=grp
    ldap.user.request: (&(objectClass=user)(UserPrincipalName={login}))
    sonar.security.realm: LDAP
    sonar.jdbc.password: {{ .Data.data.password }}
    sonar.jdbc.url: jdbc:postgresql://db-sonarqube:5432/{{ .Data.data.username }}
    sonar.jdbc.username: {{ .Data.data.username }}
    {{- end }}
---
apiVersion: v1
kind: Service
metadata:
  name: app-sonarqube
spec:
  selector:
    app: app-sonarqube
  ports:
  - protocol: TCP
    port: 9000
    targetPort: 9000
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: app-sonarqube
spec:
  rules:
  - host: sonardemo.ccs2-rd-shared.ccs.cegedim.cloud
    http:
      paths:
      - pathType: Prefix
        path: /
        backend:
          service:
            name: app-sonarqube
            port:
              number: 9000

Déployer la démo de Vault SonarQube

kubectl apply -f vault_demosonarqube.yaml --namespace vault-demopostgres

Étapes de contrôle