Gateway Deployment via Helm

Installation Steps

Pulling the helm chart

To get started with your helm chart, create a local directory to store your chart. Then run the following command to add Virtru's helm charts to your local helm repo:

helm repo add virtru-charts https://virtru-corp.github.io/virtru-charts/

To view your helm repos, run:

helm repo list

You should see virtru-charts added from the URL https://virtru-corp.github.io/virtru-charts/.

To download a chart for editing, run the following command:

helm pull virtru-charts/gateway --untar

You should see a directory called gateway created inside of your working directory.

Use cases

The first step will be to determine which gateway modes and functions you wish to utilize. The options are as follows:

• Outbound Encrypt (default option)
• Outbound Decrypt
• Outbound DLP (leverage Virtru's content scanning and DLP engine to determine if emails should be encrypted and if any additional security options should be leveraged)
• Inbound Encrypt
• Inbound Decrypt

Create secrets

There are a number of ways that Kubernetes secrets can be managed. If you do not have an existing external secret manager for your Kubernetes clusters, you can create secrets by using the appSecrets section of the values.yaml file.

Please note we strongly advise you consider using an external secrets manager. Creating secrets via the values.yaml is a default option to help get your gateway up and running more quickly.

Updating values.yaml file

This section will detail potential changes that you will need to make to your values.yaml file.

gatewayModes

For each gateway use case identified above, ensure that the specific mode's enabled key is toggled to true. The default ports are non-standard custom ports, but any port can be used as they all translate to port 25 internally on the pod.

standardConfig

• gatewayHostname - FQDN of the gateway
• primaryMailingDomain - Your primary email domain
• gatewayTransportMaps - Next hop for your gateway, defaults to Google SMTP Relay service
• inboundRelayAddresses - Determine IPs you wish to allow traffic into the gateway container from (default is open at the container level and to build firewall rules to only allow specific source IPs into the pod)
  • Default values for Gmail and Office 365 sending IPs included in the Reference section at the bottom of this document
• headers.xHeaderAuthEnabled - Defaults to true. If enabled, you must also set xHeaderAuthSecret and add the secret value to messages prior to hitting the gateway

appSecrets

Set the values based on the information below:

• Required
  • gateway-amplitude-api-key - Provided by Virtru
  • gateway-api-token-name - Provided by Virtru
  • gateway-api-token-secret - Provided by Virtru
• Optional (configuration specific)
  • If using X Header Authentication (default true)
    • gateway-xheader-auth-secret - The secret value to be added in your headers before sending mail to the gateway (example: 123456789 would mean you have to have a header on every email sent to the gateway of X-Header-Virtru-Auth:123456789)
  • If using SASL authentication upstream
    • gateway-sasl-auth-upstream - The auth path for your SMTP authentication to the next hop (example: smtp-relay.gmail.com=>gateway-service-account@example.com=>appSpecificPassword)
  • If using SASL authentication downstream
    • gateway-sasl-auth-downstream - The auth path for your SMTP authentication from the previous hop to the Virtru gateway (example: smtp-relay.gmail.com=>gateway-service-account@example.com=>appSpecificPassword)

additionalConfig

You may, depending on your email needs, wish to update a few values in this section. Below are a few of the primary variables you may wish to adjust:

• saslAuth.smtpDownstream.enabled - This will enable SASL auth for your next hop. If you choose to enable this, you will need to create the gateway-sasl-auth-upstream file in your secret detailed above
• decryptThenEncrypt - If you are using a multi gateway approach (ex: decrypt email => Scan content => re-encrypt email), this should be set to 1 (true)

Installing the gateway

Use a standard helm install command to deploy your gateway(s). An example command is listed below:

Additional Config to go live

Refer to standard documentation for Gateway configuration. You can get your endpoints to set as smart hosts by running the following command:

And there should be public endpoints you can use when relaying mail to your new gateways.