Optional: Using Vault as a certificate authority

You can use vault as a certificate authority by specifying VAULT_CA=true. This is an optional configuration and can be used with any of the configuration mode supported to handle internal certification between your containers.

If you have Vault configured as a certificate authority (CA), you can use VAULT_CA=true, which triggers /SETUP/bin/updateCerts.sh in the Docker image. For information about configuring Vault as a CA, see Managing certificates with Vault.

VAULT_CA=true is an independent configuration that you can use with any of the three modes (CONFIGURE_MODE=Vault, CONFIGURE_MODE=EnvVariables, or no configuration mode). If you are using CONFIGURE_MODE=Vault|EnvVariables, ensure that you also specify the mandatory parameters for your mode. For example, if you enable CONFIGURE_MODE=Vault and VAULT_CA=true, then you need to specify TENANT, ENVIRONMENT, and ENVTYPE because it is needed for CONFIGURE_MODE=Vault. When you read the container parameters and notice that the same variables are used in different configuration modes (such as VAULT_TOKEN), you just need to define it once as a container environment variable. The different configuration modes will share the same variables that you provide.

The parameter VAULT_CA=true also has it's own two configuration modes.

Without CONTAINER_HOSTNAME
With CONTAINER_HOSTNAME=<customHostName>

Starting a container with VAULT_CA=true but without CONTAINER_HOSTNAME

Use this method in an environment where your container variables are grouped in the form <TENANT><ENVIRONMENT><ENVTYPE><TARGETKEY>. For example, if you use VAULT to store your parameters and you are using CONFIGURE_MODE=Vault.

This method is ideal in a Docker orchestration platform such as Kubernetes or DC/OS where you can resolve <TENANT><ENVIRONMENT><ENVTYPE>. When VAULT_CA=true, the start up logic /SETUP/bin/updateCerts.sh applies the internal certification based on the unique naming pattern <TENANT><ENVIRONMENT><ENVTYPE><DOCKER_CONTAINER>.<DOMAIN_NAME> as the common_name and SubjectAlternativeName. With this mode, the host name is fixed. If you do not provide a DOMAIN_NAME, the default is default.svc.cluster.local.

For example, to start a container with the DOMAIN_NAME as txn,

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>

Starting a container with VAULT_CA=true and CONTAINER_HOSTNAME=<customHostName>

Starting with HCL Commerce Version 9.0.0.2, you can start the container with VAULT_CA=true and CONTAINER_HOSTNAME=<customHostName>. Use this method on your own custom environment where you do not have <TENANT><ENVIRONMENT><ENVTYPE>. For example, if you are using a local environment and you are not using CONFIGURE_MODE=Vault, then you will want to specify CONTAINER_HOSTNAME.

When CONTAINER_HOSTNAME is passed, the start up logic /SETUP/bin/updateCerts.sh applies the internal certification based on the CONTAINER_HOSTNAME as the certificate's common_name and SubjectAlternativeName.

For example, to start a container with host name mycontainerhostname

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>