Using Vault as a Certificate Authority

Vault can function as a Certificate Authority (CA) by enabling the VAULT_CA=true parameter. This optional configuration enhances security by handling internal certifications between containers. It integrates seamlessly with any supported configuration mode, making it suitable for diverse deployment scenarios.

Purpose and Benefits

Using Vault as a CA automates the internal certification process, ensuring secure communication between containers. This setup is particularly beneficial in environments like Kubernetes, where dynamic scaling and service discovery are essential. By leveraging Vault, you can centralize certificate management, simplify maintenance, and enhance security.

Configuring Vault as a Certificate Authority

General Configuration
  • Enabling VAULT_CA=true triggers the /SETUP/bin/updateCerts.sh script within the Docker image.
  • Vault can be used with any configuration mode:
    • CONFIGURE_MODE=Vault
    • CONFIGURE_MODE=EnvVariables
    • No configuration mode.

Ensure mandatory parameters for the chosen configuration mode are specified. For example, when using CONFIGURE_MODE=Vault and VAULT_CA=true, parameters such as TENANT, ENVIRONMENT, and ENVTYPE must be defined.

Shared Parameters
  • Variables like VAULT_TOKEN are shared across different configuration modes. Define these once as environment variables.

Configuration Modes for VAULT_CA=true

  1. Without CONTAINER_HOSTNAME
    1. Use Case

      This method is ideal for orchestrated environments like Kubernetes, where container variables follow the pattern.

    2. Hostname Logic
      1. The /SETUP/bin/updateCerts.sh script generates certifications using the pattern for common_name and SubjectAlternativeName
      2. If DOMAIN_NAME is not provided, the default value 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>
  2. Without CONTAINER_HOSTNAME
    1. Use Case

      This method is suitable for environments without the structure, such as local setups or custom environments.

    2. Hostname Logic
      1. The /SETUP/bin/updateCerts.sh script uses the value of CONTAINER_HOSTNAME as common_name and SubjectAlternativeName for certifications.
    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>