Facultatif : Utilisation de Vault comme autorité de certification
Vous pouvez utiliser un coffre comme autorité de certification en spécifiant VAULT_CA=true. Il s'agit d'une configuration facultative et peut être utilisée avec n'importe quel mode de configuration pris en charge pour gérer la certification interne entre vos conteneurs.
Si vous avez Vault configuré en tant qu'autorité de certification (CA), vous pouvez utiliser VAULT_CA=true, qui déclenche /SETUP/bin/updateCerts.sh dans l'image Docker. Pour plus d'informations sur la configuration de Vault en tant qu'autorité de certification, voir Gestion des certificats avec Vault.
VAULT_CA=true est une configuration indépendante que vous pouvez utiliser avec l'un des trois modes (CONFIGURE_MODE=Vault, CONFIGURE_MODE=EnvVariables, ou aucun mode de configuration). Si vous utilisez CONFIGURE_MODE=Vault|EnvVariables, assurez-vous que vous spécifiez également les paramètres obligatoires de votre mode. Par exemple, si vous activez CONFIGURE_MODE=Vault et VAULT_CA=true, vous devez spécifier TENANT, ENVIRONNEMENT et ENVTYPE car il est nécessaire pour CONFIGURE_MODE=Vault. Lorsque vous lisez les paramètres du conteneur et remarquez que les mêmes variables sont utilisées dans différents modes de configuration (tels que VAULT_TOKEN), vous n'avez qu'à le définir une fois comme une variable d'environnement de conteneur. Les différents modes de configuration partageront les mêmes variables que vous fournissez.
- Sans CONTAINER_HOSTNAME
- Avec CONTAINER_HOSTNAME=<customHostName>
Démarrage d'un conteneur avec VAULT_CA=true mais sans CONTAINER_HOSTNAME
Utilisez cette méthode dans un environnement où vos variables de conteneur sont regroupées sous le formulaire <TENANT><ENVIRONMENT><ENVTYPE><TARGETKEY>. Par exemple, si vous utilisez VAULT pour stocker vos paramètres et que vous utilisez CONFIGURE_MODE=Vault.Cette méthode est idéale dans une plate-forme d'orchestration Docker telle que Kubernetes ou DC/OS où vous pouvez résoudre <TENANT><ENVIRONMENT><ENVTYPE>. Si VAULT_CA=true est utilisé, la logique de démarrage /SETUP/bin/updateCerts.sh applique la certification interne basée sur le modèle de dénomination unique <TENANT><ENVIRONMENT><ENVTYPE><DOCKER_CONTAINER>.<DOMAIN_NAME> comme common_name et SubjectAlternativeName. Avec ce mode, le nom d'hôte est corrigé. Si vous ne fournissez pas de DOMAIN_NAME, default.svc.cluster.local est le nom par défaut.
docker run -it -e LICENSE=accept \
-e VAULT_TOKEN=<vault_token > \
-e VAULT_URL=<vault_url. For example, http://IP:Port/v1> \
-e VAULT_CA=true \
-e TENANT=<tenantValue> \
-e ENVIRONMENT=<environmentValue. For example, non-prod> \
-e ENVTYPE=<envtypeValue. For example, auth> \
-e DOMAIN_NAME=<The container's hostname, which will be used to apply certification. For example, txn> \
-e <Parameter1>=<Value1>
-e <Parameter2>=<Value2>
....
<Docker_Image>Démarrage d'un conteneur avec VAULT_CA=true mais sans CONTAINER_HOSTNAME
En commençant avec 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 <TENANT><ENVIRONMENT><ENVTYPE>. Par exemple, si vous utilisez un environnement local et que vous n'utilisez pas CONFIGURE_MODE=Vault, vous devrez spécifier CONTAINER_HOSTNAME.Lorsque CONTAINER_HOSTNAME est adopté, la logique de démarrage /SETUP/bin/updateCerts.sh applique la certification interne basée sur le CONTAINER_HOSTNAME comme common_name et SubjectAlternativeName du certificat.
docker run -it -e LICENSE=accept \
-e VAULT_TOKEN=<vault_token > \
-e VAULT_URL=<vault_url. For example, http://IP:Port/v1> \
-e VAULT_CA=true \
-e CONTAINER_HOSTNAME=mycontainerhostname
-e <Parameter1>=<Value1>
-e <Parameter2>=<Value2>
....
<Docker_Image>