Gestion des certificats avec Vault

Par défaut, les conteneurs Docker HCL Commerce prennent en charge de l'utilisation de Vault comme système de gestion des certificats.

Pour plus d'informations, voir Vault.

Certificats internes

Pour la certification interne entre les conteneurs Docker HCL Commerce, vous devez vous assurer que le nom commun (CN) de votre certificat et "SubjectAlternativeName" peuvent correspondre au nom d'hôte que les conteneurs Docker utiliseront. De plus, lorsque d'autres conteneurs source se connectent à un conteneur cible, le conteneur source doit utiliser le nom d'hôte du conteneur cible. Il existe une logique de vérification stricte pour vérifier si le nom d'hôte utilisé dans une requête est le même que SubjectAlternativeName dans le certificat du conteneur cible. Si les noms d'hôte ne correspondent pas, la connexion échoue.

Voici les SubjectAlternativeNames de la certification interne par défaut incluse dans les HCL Commerce conteneurs Docker :

SubjectAlternativeName [
  DNSName: *
  DNSName: app
  DNSName: web
  DNSName: search
  DNSName: store
  DNSName: tooling-web
  DNSName: store-web
  DNSName: query
  DNSName: data-query
  DNSName: ingest
  DNSName: nifi
  DNSName: registry
  DNSName: elasticsearch
  DNSName: zookeeper
  DNSName: localhost
  DNSName: search_master
  DNSName: search_repeater
  DNSName: search_slave
]

Si vous n'utilisez pas les noms d'hôte par défaut, vous devez reconfigurer les connexions entre les conteneurs. Pour apprendre à créer vos propres certificats, voir Gestion manuelle des certificats. Sinon, vous pouvez utiliser Vault comme autorité de certification (CA).

Configuration de Vault pour agir en tant qu'autorité de certification (CA)

Vous pouvez configurer Vault en tant que CA avec un backend PKI. Si vous voulez utiliser cette méthode, vous devez coder en dur le nom de backend PKI backend comme "selfserve_production_pki" et le rôle PKI comme "generate-cert". En supposant que Vault est installé, déscellé et que vous avez un environnement doté d'un client Vault qui peut se connecter au serveur Vault avec l'adresse et le jeton appropriés, vous pouvez effectuer les étapes suivantes pour configurer Vault en tant qu'autorité de certification.

Créez un backend de type PKI.

vault secrets enable -path=selfserve_production_pki -description="SelfServe Root CA" -max-lease-ttl=87600h pki

Activez la fonctionnalité PKI de Vault pour agir en tant qu'organisation de l'autorité de certification (CA) pour délivrer des certificats.
1. Exécutez la commande pour créer un certificat d'autorité de certification racine.
```
vault write selfserve_production_pki/root/generate/internal  common_name="selfserve_production_pki Root CA"  ttl=87600h  key_bits=4096  exclude_cn_from_sans=true
```
2. Exécutez la commande suivante pour créer un rôle qui sera utilisé pour délivrer la certification pour chaque conteneur Docker.
```
vault write selfserve_production_pki/roles/generate-cert key_bits=2048 max_ttl=8760h allow_any_name=true enforce_hostnames=false
```
  La commande se termine avec un message Réussite ! Les données sont consignées dans : selfserve_production_pki/roles/generate-cert.

Vérifiez si vous pouvez obtenir la certification de PKI.

curl -sS -X POST -H "X-Vault-Token:<Vault_token>" -d "{\"common_name\":\"<common_name>\", \"ttl\":\"1344h\"}" http://<Vault_IP>:8200/v1/selfserve_production_pki/issue/generate-cert

Vous devriez recevoir une réponse similaire à la sortie qui suit :

Key Value
--- -----
lease_id cuddletech_ops/issue/web_server/e03318f2-d005-8196-4ed5-a42f9cd55238
lease_duration 2591999
lease_renewable false
certificate -----BEGIN CERTIFICATE-----
MIIE7jCCAtagAwIBAgIUN+vXFuIf42v1SW+mDROUVAm+lUMwDQYJKoZIhvcNAQEL
BQAwKTEnMCUGA1UEAxMeQ3VkZGxldGVjaCBPcHMgSW50ZXJtZWRpYXRlIENBMB4X
DTE2MDcwOTA5MzE1N1oXDTE2MDgwODA5MzIyN1owIjEgMB4GA1UEAwwXc3NsX3Rl
...
issuing_ca -----BEGIN CERTIFICATE-----
MIIF5DCCA8ygAwIBAgIUdhJTQb4YmCyhUUr48L20o0R+dFkwDQYJKoZIhvcNAQEL
...
private_key -----BEGIN RSA PRIVATE KEY-----
MIIEowIBAAKCAQEApBabDpPZIloRQUpro3tQEls0FEFvsvfraQzQJLD2dicSPZ2s
CqYyT8OXMclrapG7KKTYp79AaTW8LgNg3WvCzoMGDfhLL9m0QomzrMDzoW8Q7iQO
1MV4f6JXjGMbOMMXatKQlO32fLZln8m+/yJ3pOW0S6uatFzZ/N3+ed+gDuUc7eAO
...
private_key_type rsa
serial_number 37:eb:d7:16:e2:1f:e3:6b:f5:49:6f:a6:0d:13:94:54:09:be:95:43
'''

Démarrage d'un conteneur avec VAULT_CA=`true`

Une fois que vous avez configuré Vault en tant qu'autorité de certification, vous pouvez démarrer le conteneur avec le paramètre VAULT_CA=true. Utilisez cette méthode dans une plate-forme d'orchestration Docker telle que Kubernetes. Lorsque VAULT_CA=true, les scripts suivent le

TENANTENVIRONMENTENVTYPEcontainer_name.DOMAIN_NAME

modèle d'application des certifications. Avec ce mode, le nom d'hôte est corrigé. Si ce DOMAIN_NAME n'est pas renseigné, la valeur par défaut est default.svc.cluster.local.

Démarrage d'un conteneur avec VAULT_CA=`true` et CONTAINER_HOSTNAME=`customHostName`

A compter de HCL Commerce version 9.0.0.2, vous pouvez démarrer le conteneur avec VAULT_CA=true et CONTAINER_HOSTNAME=customHostName. Utilisez cette méthode sur votre propre environnement personnalisé où vous n'avez pas les éléments TENANTENVIRONMENTENVTYPE. Lorsque CONTAINER_HOSTNAME est transféré, la logique de démarrage /SETUP/bin/updateCerts.sh applique la certification interne en fonction du nom d'hôte que vous fournissez. Par exemple, pour commencer Store server Docker container avec le nom d'hôte mycustomstore

docker run -d -e LICENSE=accept  \
    -e SPIUSER_NAME=spiuser \
    -e SPIUSER_PWD=<Your spiuser password that you encrypted with wcs_encrypt.sh>
    -e VAULT_TOKEN=<vault_token > \
    -e VAULT_URL=<vault_url. For example, http://IP:Port/v1> \
    -e VAULT_CA=true \  
    -e CONTAINER_HOSTNAME=mycustomstore    
    <Store_Docker_Image>

Certificats externes

Pour une communication SSL sécurisée entre HCL Commerce et un système externe, assurez-vous d'importer les certificats appropriés dans votre magasin de clés et votre magasin de confiance. Assurez-vous également que votre code de personnalisation référence le bon nom de certificat pour cette communication. Vous pouvez placer vos certificats tiers dans Vault pour permettre au script de configuration updateCerts.sh d'importer automatiquement les certificats dans votre magasin de clés.

Pour inclure des certificats externes :

Créez un groupement de certificats (certBundle) pour votre certificat externe.

Remarque : Si l'objectif d'un groupement de certificats que vous créez est de faire confiance à un certificat affecté à un système externe, vous devez uniquement indiquer issusing_ca. Dans ce cas, les valeurs certificate et private_key peuvent être vides ou entièrement exclues de la définition certBundle.

Un certBundle est un objet JSON contenant un certificat, sa clé privée et le certificat ou la chaîne de certificats de l'autorité de certification (CA). Voici un exemple de certBundle.

{ 
 "certificate": "certificate", 
 "private_key": "private_key", 
 "issuing_ca": "ca_certificates" 
}

Le contenu du groupement de certificats est le suivant.

La valeur certificate contient le certificat, au format PEM base64, qui doit être affecté au serveur d'applications HCL Commerce spécifié :

La valeur de ce certificat doit être encapsulée dans les lignes de texte -----BEGIN CERTIFICATE-----\n et -----END CERTIFICATE-----.
La valeur du certificat ne doit être constituée que d'une ligne de texte et se terminer par un \n, pour indiquer la fin de la ligne.

Voici un exemple de valeur certificate.

La valeur private_key contient la clé privée correspondant au certificat, et elle est requise pour installer le certificat pour le serveur d'applications HCL Commerce :

La valeur de ce certificat doit être encapsulée dans les lignes de texte -----BEGIN RSA PRIVATE KEY-----\n et -----END RSA PRIVATE KEY-----.
La valeur du certificat ne doit être constituée que d'une ligne de texte et se terminer par un \n, pour indiquer la fin de la ligne.

Voici un exemple de valeur certificate.

La valeur issuing_ca contient le certificat de l'autorité de certification (CA) ou la chaîne de certificats de l'autorité de certification qui sont utilisés pour valider le certificat. Par exemple, si le certificat est signé par un certificat de CA intermédiaire, le certificat de CA intermédiaire et son certificat de CA racine doivent être tous deux inclus dans la valeur issuing_ca.

La valeur de ce certificat doit être encapsulée dans les lignes de texte -----BEGIN CERTIFICATE-----\n et -----END CERTIFICATE-----.
La valeur du certificat ne doit être constituée que d'une ligne de texte et se terminer par un \n, pour indiquer la fin de la ligne.

Voici un exemple de valeur issuing_ca.

Ecrivez les données certBundle dans Vault.
Important : Chaque certBundle doit avoir un nom unique. Par exemple, cert1 et cert2.
Par exemple, la commande curl suivante écrit le contenu du certBundle, cert_bundle_json, dans la définition cert1 sous un client et un environnement spécifiés.
```
curl -sS -X POST -H "X-Vault-Token:<Vault_token>" -d "{\"value\":<cert_bundle_json>}" http://<Vault_IP>:8200/v1/<tenant>/<environment>/certs/cert1 
```
Indiquez quels certificats certBundle doivent être déployés sur chaque serveur d'applications HCL Commerce.
Pour ce faire, mettez à jour la définition de certsBundle sur le client et l'environnement spécifiés, {tenant}/{environment}/certsBundle, au format d'objet JSON suivant.
```
{ 
    "tsapp": "cert1,cert2", 
    "crsapp": "cert1,cert2", 
    "searchapp": "cert1,cert2", 
    "xcapp": "cert1,cert2", 
    "storeapp": "cert1,cert2" 
} 
```
Dans cet exemple, les certsBundle cert1 et cert2 sont déployés et appliqués dans cinq serveurs d'applications HCL Commerce.
Déployez vos applications HCL Commerce pour appliquer les certificats externes.
Les certificats ne seront pas appliqués par le script d'utilitaire updateCerts.sh sans déploiement pour le déclencher.