Deploying a development Vault for Commerce+

Vault is used to store HCL Commerce+ environment configurations and secrets. It is also used as a Certification Authority (CA), to issue certificates to Commerce+ servers and allow them communicate securely over SSL.

The hcl-commerce-vault-helmchart Helm Chart deploys Vault for use as a remote configuration center, storing Commerce+ environment data, and acting as the certification agent to issue certificates to each Commerce+ application server based on their unique service names. The Vault must be deployed before deploying the Commerce+ application. Once Vault are deployed, it can be used to deploy and control multiple Commerce+ environments. After Vault is started, it can run scripts to load Commerce+ environment configuration data as specified in values.yaml, and can also configure a Public Key Infrastructure (PKI) back-end to issue certificates, if enabled via the vault.vaultLoadData configuration.

Before you begin

Obtain the hcl-commerce-helmchart and hcl-commerce-vault-helmchart from the My HCLSoftware portal. For up-to-date release information, see Downloading HCL Commerce+ software.
Note: Review the sample values.yaml configuration file provided with the hcl-commerce-vault helmchart and update it according to your environment and database type. Ensure that the environment variables (for example, DEV Auth, DEV Live, QA Auth, QA Live) are set consistently and aligned with the database type being deployed.

The provided Helm Chart attempts to pull Vault Docker images from DockerHub. If you use the default settings, ensure that your environment can connect to the Internet. Otherwise, you can download the Docker images and place them into a private Docker Image Repository.

The relevant configuration is defined as follows:


Attribute name	Value	Usage
`vault.imageRepo`	docker.io	Defines the Docker image repository for Vault images.
`vault.vaultImageName`	`hashicorp/vault`	The Vault Docker image name.
`vault.vaultImageTag`	2.0.3	The Vault Docker image tag.
`test.image`	`docker.io/centos:latest`	The Helm Test command uses the Centos Docker image. This is used for sanity testing purposes.

Note:

Ensure that you use the versions specified in the table above. These versions are tested and are certified to work with Commerce+. There are no guarantees that other tagged versions will function with Commerce+ as expected.
Resource limitations are not defined for Vault usage with Commerce+. Their use with Commerce+ in this provided configuration is simply to support deployment of a non-production environment, and are not designed or intended for use in any performance application. This must be considered when planning and configuring your production environment with high availability and more strict application security in mind.

As part of the Vault deployment, Vault will create a Vault token secret within the  commerce  namespace. It will be created within this namespace so that the Commerce+ application can obtain the Vault token from that secret. This requires that the commerce namespace exists before you can deploy Vault.
If  the commerce  namespace has not been created, you can create it with the following Kubernetes command:  kubectl create ns commerce. If you plan to deploy Commerce+ in other namespaces, then you must also create those namespaces at this point, and list all of the namespaces in the commerceNameSpaces section of your configuration file.
It is also recommended to deploy Vault in a separate namespace, such as  vault, to serve for all Commerce+ environments. If you do not  have a dedicated Vault  namespace, then you can create it now with the same command: kubectl create ns vault.
Before deploying Vault, you must plan how you are going to deploy Commerce+, and then modify the data accordingly within your values.yaml file that will be loaded to the Vault as a postStart action. In Vault, a tenant name will be used as a secret mount path. This secret path will contain one or more environments, and each environment contains the key-value (KV) pairs for that environment. The environment level KV pairs will be under environment path directly, while auth and live instance specific KV pairs are under auth or live.
For example:
```
/Demo                                                        # tenant path 
/qa                                                      # env path 
internalDomainName: commerce.svc.cluster.local       # environment level properties 
… 
/auth                                                # auth instance path 
dbHost: myDb.com                                 # auth instance level properties 
… 
/live                                                # live instance path 
dbHost: myLiveDb.com                             # live instance level properties 
 
```
Create a copy of the Vault configuration file, values.yaml for use in your custom Vault deployment.
It is strongly recommended to not modify the default  values.yaml  file for your deployment. Instead, make a copy of the file for customization, for example, my-values.yaml.

Procedure

Define a Certificate Authority (CA) certificate, and configure how it is to be used by Vault.
The provided Helm Chart deploys vault in development mode to bypass the unseal process. In this mode all data will be stored in memory only. Configuration data is defined in the Helm values file, so it is loaded every time Vault is redeployed or restarted. However, the root CA certificate can not be persisted unless it is defined and persisted in a secret. Therefore, the Helm Chart allows either specifying, or automatically generating a CA certificate, and then persisting it within a TLS secret.
Select from one of the following options:
- Allowing the Vault Helm Chart to automatically generate and persist the CA certificate.
  To allow the Vault Helm Chart to automatically create a CA certificate and create a TLS secret, set the following configuration parameters:
  - externalCA.enabled to true
  - externalCA.autoCreate to true
  This automatic creation logic also requires the Support container image. Ensure that it is configured using the supportC.imageRepo, supportC.image and  supportC.tag parameters.
  Note: Automatic CA certificate generation is only implemented during the Helm Chart installation (that is, using helm install). Therefore, if you have deployed the Vault using the previous version of the Helm Chart, or if you want to modify your CA certificate after deployment, you must delete and install the Helm Chart again in order to implement this method of CA certificate generation.
- Generating and specifying your CA certificate manually.
  Create a self-signed CA certificate and configure it for use in the Vault deployment.
  1. Generate the self-signed CA certificate.
    1. Create a private key, private.key.
      openssl genrsa -out private.key 2048
    2. Create a CA certificate based on the private key.
      openssl req -x509 -new -nodes -key private.key -days 730 -out ca.pem -config req.conf
      Where the req.conf configuration file contains the following specification.
      [ req ] prompt=no distinguished_name=dn x509_extensions=ext [ dn ] CN=My Company CA [ ext ] basicConstraints=CA:TRUE
    3. create a TLS certificate in the vault namespace for use with Vault, using kubectl.
      kubectl create secret tls my-vault-ca --cert=ca.pem --key=private.key -n vault
    4. Update your Vault deployment configuration file (based on the provided values.yaml)
      externalCA: enabled: true existingSecretName: 'my-vault-ca' autoCreate: false
Modify the deployment configuration values, based on the provided values.yaml file.
1. Change the tenant name if you want to name it differently. If you change the tenant name here, you must also change the tenant name in the provided Commerce+ Helm Chart values to match.
2. By default, the gateway for the Vault service is enabled, allowing access to the Vault user interface. Set gateway.enabled to false to disable the gateway.
3. Populate the commerceNameSpaces section with your Commerce+ namespaces.
  For example, if you want to deploy two Commerce+ environments dev and qa in the commerce-dev and commerce-qa namespaces, you must run the following commands:
```
kubectl create ns commerce-dev 
kubectl create ns commerce-qa
```
  And add the following to your commerceNameSpaces section:
```
commerceNameSpaces:  
- commerce-dev 
- commerce-qa
```
4. Update the following vault deployment configuration values.
  - Update  the imageRepo, vaultImageName,  and  vaultImageTag  values if you want to test different Vault images.
    This is not recommended.
  - Update  vaultToken  to the one that you want to use.
    If modified from the default value, you must encode your token in Base64 by running echo -n newToken | base64, and use it to update the vaultTokenBase64  value.
  - Enable and update the vaultLoadDataWithSecret section to improve the security of your vault data. Also ensure that vaultLoadData is enabled in order to load data.
    With this option enabled, you can ignore the vaultData section of the Helm Chart. Any sensitive key value pairs are now shielded from being exposed in the deployment configuration files.
    If you choose this method then you must manually create a secret, and put the secret name in the secretName field.
    A sample yaml configuration file with this configuration is located in the sample_secret directory. Use this sample to ensure that your configuration is made correctly.
  - Update the values under  vaultData to reflect your environment.
    For example, update your database information.
Install the Helm Chart.
Run the following command:
```
helm install vault- ./hcl-commerce-vault -f my-values.yaml -n vault
```
Where:

vault

The release name.

./hcl-commerce-vault

The path to the Helm Chart.

my-values.yaml

Your custom configuration file based on the provided values.yaml.

vault

The separate namespace you created for Vault.

Verify the deployment of Vault, and verify the Chart.

Run kubectl get pods -n vault to ensure that vault-xxxx displays 1/1 in the READY column.

NAME                            READY   STATUS    RESTARTS   AGE
vault-676d9c5485-hc44b   1/1     Running   0          20d

Run kubectl get secret vault-token-secret -n commerce to list the secret in your commerce namespace, to ensure that the secret has been created.
For example:
```
kubectl get secret vault-token-secret -n commerce 
NAME                 TYPE     DATA   AGE 
vault-token-secret   Opaque   1      7m44s
```

Run helm test vault -n vault to verify the Chart. You should see an output similar to the following.

helm test vault -n vault
Pod vault-health-test pending
Pod vault-health-test pending
Pod vault-health-test pending
Pod vault-health-test running
Pod vault-health-test succeeded
NAME: vault
LAST DEPLOYED: Tue May 12 00:44:29 2020
NAMESPACE: vault
STATUS: deployed
REVISION: 1
TEST SUITE:     vault-health-test
Last Started:   Thu Jun 25 16:06:27 2020
Last Completed: Thu Jun 25 16:06:35 2020
Phase:          Succeeded

Results

Vault is configured and deployed.

You can update the configuration by editing your vaultData configuration file and running the following command:

helm upgrade vault ./hcl-commerce-vault -f my-values.yaml -n vault

Note: If you use vaultLoadDataWithSecret to load data, you can only update vault values by updating the data secret and then deleting the existing vault pod to force a restart.

You can uninstall the Helm Chart at any time by running helm delete vault -n vault.