Step 3 - Add secrets in Key Vault

3.1 - Azure Storage Connection String

To enable Glasswall Halo's access to the reporting storage account ('saname'), the connection string is required in Key Vault.

• You can retrieve the connection string through the Azure Portal or via the Azure CLI as shown in the example below. Just remember to enter your storage account and resource group.

az storage account show-connection-string --name "${saname}" -g "${rgp}"

• Enter your connection string (highlighted in the screenshot) by replacing ${saconnstring}, and enter your Key Vault by replacing ${kvname} (as below).

az keyvault secret set --name "azure-storage-connectionstring" --vault-name "${kvname}" --value "${saconnstring}"

3.2A - Database Option 1 - MongoDB Connection String

To enable Glasswall Halo's connection to the Database, the connection string of the MongoDB should be created in Key Vault.

• You can retrieve the CosmosDB connection string (MongoDB compatible) through the Azure Portal or via the Azure CLI as shown in the example below.
  
  Note: remember to enter your Cosmos DB Account Name and Resource Group.
  
  The command will provide a list of 4 connection strings. You may use any one of the first 2 connections strings. You cannot use the Read-Only connection strings.

az cosmosdb list-connection-strings --name "${cosmosdb_name}" -g "${rgp}"

• Enter your connection string (highlighted in the screenshot) by replacing ${mongodb_connstring}, and enter your Key Vault by replacing ${kvname} (as below).

az keyvault secret set --name "mongodb-connectionstring" --vault-name "${kvname}" --value "${mongodb_connstring}"

Add the MongoDB passwords to Azure keyvault as a secret

Note: if you have previously configured and setup MongoDB within Azure and have created your MongoDB connection string as listed above, you can skip this step.

If not, to enable Glasswall Halo's Policy API to create and manage the policies in MongoDB, and Asynchronous API to create and manage the requests, MongoDB needs to be deployed using Helm charts listed in Step 8. 

Two users will be created by the MongoDB Helm chart and the corresponding user's password needs to be set in the Vault secret.

az keyvault secret set --name "mongodb-cdrp-password" --vault-name "${kvname}" --value "<cdrp-user-password>"
az keyvault secret set --name "mongodb-admin-password" --vault-name "${kvname}" --value "<admin-user-password>"

3.2B - Database Option 2 - CosmosDB Connection String

If CosmosDB is setup instead of MongoDB, the Cosmos connection string should be added to Key Vault.

You can retrieve the connection string of CosmosDB through the Azure Portal or via the Azure CLI as shown in the example below. Just remember to enter your Cosmos DB account name and resource group. The command will provide a list of 4 connection strings. You may use any one of the first 2 connections strings. You cannot use the Read-Only connection strings.

az cosmosdb list-connection-strings --name "${cosmosdb_name}" -g "${rgp}"

 Enter your connection string (highlighted in the screenshot) by replacing `${mongodb_connstring}`, and enter your Key Vault by replacing `${kvname}` (as below).

az keyvault secret set --name "mongodb-connectionstring" --vault-name "${kvname}" --value "${mongodb_connstring}"

3.3 - Menlo API Key

To enable API key-based authentication in the Menlo API, add a secret menlo-api-key with an API key you would like to use.

az keyvault secret set --name "menlo-api-key" --vault-name "${kvname}" --value "<strong-api-key>"

3.4 - [Optional] Add ReversingLabs credentials 

To integrate the Halo with Reversing Labs, add the credentials of the Reversing Labs to the KeyVault. Replace `${reversinglabs_username}` and `${reversinglabs_password}` with actual username and password.

az keyvault secret set --name "halo-reversinglabs-username" --vault-name "${kvname}" --value "${reversinglabs_username}"
az keyvault secret set --name "halo-reversinglabs-password" --vault-name "${kvname}" --value "${reversinglabs_password}"

3.5 - [Optional] Add ICAP MTLS certificates

ICAP servers can be configured for mutual client authentication using the MTLS certificates. The certificates will be mounted to the ICAP server pods using the Kubernetes secrets. Add the server certificates and certificate authority to the Keyvault so that they can be synced to Kubernetes secrets.

az keyvault secret set --vault-name "${kvname}" --name tls-server-cert -f <path/to/mtls-server-cert.pem>
az keyvault secret set --vault-name "${kvname}" --name tls-server-key -f <path/to/mtls-server-key.pem>
az keyvault secret set --vault-name "${kvname}" --name tls-cafile -f <path/to/mtls-ca-cert.pem>

Continue  Need help?