Skip to main content
Version: 2.16.0

Step 3 - Add secrets in Key Vault

Storage account 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}"

image.png

  • 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 Halo's connection to the Database, the connection string of the MongoDB should be created in the Key Vault

  • You can retrieve the connection string of the CosmosDB (MongoDB compatible) through the Azure Portal or via the Azure CLI as shown in the example below.

Note: remember to enter your CosmosDB 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 Key Vault as a secret​

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

If not, to enable Glasswall Halo's Policy Management 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 set up 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 connection 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 - Optional: Add ReversingLabs credentials​

To integrate Halo with ReversingLabs, add the credentials of ReversingLabs to the Key Vault. 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.4 - Optional: Add ICAP MTLS certificates​

ICAP servers can be configured for mutual client authentication using MTLS certificates.

The certificates will be mounted to the ICAP server pods using Kubernetes secrets. Add the server certificates and certificate authority to the Key Vault 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>

3.5 - Optional: Configure storage monitoring for M365​

To enable M365 storage monitoring integration, you’ll need to add your Microsoft Entra app registration credentials to the Key Vault.

This integration requires the following values:

  • Client ID
  • Tenant ID
  • Client secret

Use the commands below to add these secrets to your Key Vault:

az keyvault secret set --name "graphapi-clientid" --vault-name "${kvname}" --value "<client_id>"
az keyvault secret set --name "graphapi-tenantid" --vault-name "${kvname}" --value "<tenant_id>"
az keyvault secret set --name "graphapi-clientsecret" --vault-name "${kvname}" --value "<client_secret>"

If you don’t have these values yet, refer to our Storage Monitoring M365 Setup Guide for instructions on how to obtain them.

Continue

Need help?

Last updated on