Virtru Private Keystore (for Google Workspace CSE) 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/cse --untar

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

Configure IDP

To use Google's CSE service, you must have a 3rd party identity provider configured to authenticate users to the CSE service. Documentation on Google's requirements can be found here.

Provision SSL Certificate

Virtru's KMS for Google CSE runs on a secure connection from Google to the service. The certificates, for this service, will be mounted into the running container. When filling out the values.yaml file in the section below, you will need the private key and certificate chain available to you.

Updating values.yaml file

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

appConfig

• jwksAuthnIssuers - A base-64 encoded map of accepted Authentication issuer ids (from the authentication JWT) to the URL where the issuer publishes its JSON Web Keyset. This is dictated via the IDP. In the example provided it is Google OAuth
  • Example command to base-64 encode:
    • echo '{ "https://accounts.google.com": "https://www.googleapis.com/oauth2/v3/certs" }' | base64
• jwksAuthzIssuers - A base-64 encoded map of accepted Authorization issuer ids (from the authorization JWT) to the URL where the issuer publishes its JSON Web Keyset. This is dictated by Google and is filled out by default
• jwtAud - A base-64 encoded JSON map of JWT audiences for authorization and authentication. The authz audience, which is sent by Google, will always be cse-authorization, but the authn audience will be configured through the customer’s IDP. In the example provided the authn audience is Google OAuth
  • Example command to base-64 encode:
    • echo '{ "authn": "00000000000000000.apps.googleusercontent.com", "authz":"cse-authorization" }' | base64
• jwtKaclsUrl - URL for your CSE service. This should match the SSL certificate provisioned in the previous steps
• useCks - Default false. Switch to true if using a Virtru CKS in tandem with your CSE KMS
• cksUrl - Leave as default if not using CKS. If using CKS, this is the FQDN of your running CKS service (example: https://cks.example.com)

appSecrets

In the appSecrets section, the hmac, secretKey, and cksHmac (if using CKS) sections must be the plaintext values for your secrets, while in ssl you must base-64 encode the private key and certificate.

• hmac.tokenId - Provided by Virtru
• hmac.tokenSecret - Provided by Virtru
• secretKey - A named, base-64 encoded key for CSE encryption.
  • If your organization is using the CKS, you may comment out this variable as it will not be needed.
  • This is required if not using CKS. Format is mykeyname:base64encodedkey. See example below:
  • If your key's decoded value is testkey, your secretKey value should be mysupersecretkey:dGVzdGtleQo=, where dGVzdGtleQo= is testkey base-64 encoded.
  • Example command to get a randomly generated key into a local TXT file:
    • echo "my-key-name:$(openssl rand 32 | base64)" 2>&1 | tee cseSecret.txt
• ssl.privateKey - Your certificate's private key, base-64 encoded
  • <Base64 encoded SSL Key Value>
  • Command: cat csesrv.customer.com.key | base64
• ssl.certificate - Your certificate's cert chain, base-64 encoded
  • <Base64 encoded SSL Cert Value>
  • Command: cat csesrv.customer.com.crtchain | base64
• cksHmac.tokenId - The tokenId from your CKS configuration (only used if useCks is set to true)
• cksHmac.tokenSecret - The encryptedToken secret from your CKS configuration (only used if useCks is set to true)

Installing the CSE

Use a standard helm install command to deploy your CSE. An example command is listed below:

Additional Config to go live

Refer to standard documentation for CSE configuration in Google Admin. You can get your endpoint for your DNS record by running the following command:

And there should be public endpoints you can use when relaying traffic from Google to your new CSE.

Next Step

Google Workspace Configuration

Follow the steps from Google for connecting your CSE server to your Google Workspace tenant

https://support.google.com/a/answer/10742487?hl=en&ref_topic=10742486