Skip to main content

Who is this article for?

Code42 for EnterpriseSee product plans and features
CrashPlan for Small Business 

CrashPlan for Small Business, no.

Code42 for Enterprise, yes.

Link: Product plans and features.

This article applies to Cloud.

Code42 Support

Configure a Vault server to hold your Code42 archive keystore

Overview

External keystores mean that even in the Code42 cloud environment, you can fully control the encryption keys that secure your backed-up data. The keys are stored separately from the Code42 cloud, in a Vault keystore system. Vault is a third-party application specifically built to secure secrets. This article describes how to configure a private, self-administered Vault server to store Code42 encryption keys.

Once you have your Vault server running and tested as described in this article, move your Code42 keys into Vault by following the instructions for migrating keys to a new keystore.

Let Code42 manage your keys
Instead of managing your encryption keys in Vault, Code42 can manage your keys for you. See our Encryption Key Management overview for details. For more information, contact your Customer Success Manager (CSM) for enterprise support.

Considerations

Vault is not a Code42 product
Our Customer Champions can assist you with migrating your keystore to your private, self-administerd Vault. Customer Champions cannot, however, provide assistance with Vault-specific tasks, such as upgrade, installation, configuration, networking, and exporting certificates. For assistance with Vault, consult the Vault documentation.

Vault versions

To ensure secure operation, install the latest Vault version from the Vault downloads page. Previous versions are available from the Vault releases page

Vault uses two SSL certificates

A Vault server connecting with the Code42 cloud uses two CA-signed SSL certificates:

  • Your Vault domain certificate secures your Vault server's domain (for example, vault.example.com). It provides encryption for all communications between Vault and the Code42 cloud. It's the same process at work in most HTTPS connections between clients and servers.
  • Your Vault user/administrator certificate authenticates the user of your Vault server who administers your Code42 cloud key storage. Your Vault server uses this certificate to authenticate and authorize requests from your Code42 cloud organization.

Before you begin

Install a Vault server

Install a Vault server at a location available to the Code42 cloud. For system requirements, see the Vault Reference Architecture guide. 

  1. Set up a machine or virtual machine with network access that allows TLS/HTTPS communication with the Code42 cloud.
  2. Plan storage capacity of roughly 1 KB for each of your Code42 users.
  3. Download a Vault package for that machine's operating system.
  4. Install and configure a Vault server as described by the Vault documentation
  5. Connect your Vault server to whatever storage backend suits your purposes.

Back up Vault

To guard against loss of your encryption keys, make sure that you back up your Vault. For Vault's backup instructions, see the Vault Disaster Recovery Replication guide.

Back up your Vault!
When you create a private keystore, create a scheduled process to back it up.
Losing a self-administered private keystore is catastrophic. A wide range of Code42 functions fail. You cannot create new users. You cannot replace a lost or damaged device from backup. You cannot restore data via the console. The only sure way to protect your data is to restart all user backups from scratch.

Steps

Sample commands
The commands below are samples only. They illustrate configuration of a Vault server on a Linux operating system. Code42 makes no guarantees regarding their suitability for your environment.

Step 1: Configure your Vault to work with Code42

To allow the Code42 cloud access to your encryption keys, configure your Vault server. For more information about configuring Vault, see Vault's documentation

Change the values in the examples below as needed for your environment.

  1. Set environment variables:
    1. Set Vault_ADDR to the Vault external DNS, including the protocol (https) and port mapping (8200):
      export VAULT_ADDR="https://vault.example.com:8200"
      
    2. Set Vault_DNS to the Vault external DNS name:
      export VAULT_DNS="vault.example.com"
      
  2. Enable the secrets engine.
    1. Enable the secrets engine with the kv option:
      vault secrets enable -path=secret kv
      
    2. Enable certificate authentication:
      vault auth enable cert
      
    3. Tune Vault to issue short-lived authentication tokens for TLS connections:
      vault secrets tune -default-lease-ttl=60s auth/cert
      
    4. Mount the Vault public key infrastructure (PKI):
      vault secrets enable pki
      
    5. Tune Vault to set the life span of the SSL certificates it generates;
      vault secrets tune -max-lease-ttl=87600h pki
      
  3. Generate certificates.
    1. Generate and configure CA_cert.crt:
       vault write -field=certificate pki/root/generate/internal common_name="crashplan.com" ttl=87600h > CA_cert.crt
       vault write pki/config/urls issuing_certificates="http://${VAULT_DNS}/v1/pki/ca" crl_distribution_points="http://${VAULT_DNS}:8200/v1/pki/crl"
      
    2. Generate intermediate certificates:
       vault secrets enable -path=pki_int pki
       vault secrets tune -max-lease-ttl=43800h pki_int
       vault write -format=json pki_int/intermediate/generate/internal common_name="crashplan.com Intermediate Authority" ttl="43800h" | jq -r '.data.csr' > pki_intermediate.csr
       vault write -format=json pki/root/sign-intermediate csr=@pki_intermediate.csr format=pem_bundle ttl="43800h" | jq -r '.data.certificate' > intermediate.cert.pem
       vault write pki_int/intermediate/set-signed certificate=@intermediate.cert.pem
      
    3. Create a role to generate credentials:
      vault write pki_int/roles/cpRole allow_any_name="true" allow_subdomains=true client_flag=true max_ttl="720h"
      
    4. Issue the crashplan.com user certificate and parse it:
      vault write pki_int/issue/cpRole common_name="crashplan.com" ttl="24h" -format=json > certs.json
      cat certs.json | jq -r '.data.ca_chain[0]' > ca_chain.pem
      cat certs.json | jq -r '.data.certificate' > certificate.pem
      cat certs.json | jq -r '.data.private_key' > private_key.pem
      
  4. Create policies.
    1. Create crashplanPolicyFile.hcl with the following policy entries:
      path "pki/issue/*" {capabilities = ["create","read", "update", "delete", "list"]}
      path "sys/policy/*" {capabilities = ["create", "read", "update", "delete", "list"]}
      path "auth/cert/certs/*" {capabilities = ["create", "read", "update", "delete", "list"]}
    2. Write the policy and authorize the certificate:
      vault policy write crashplanPolicy crashplanPolicyFile.hcl
      vault write auth/cert/certs/crashplanUser display_name="crashplanUser" policies=crashplanPolicy certificate=@certificate.pem ttl=3600
      
  5. Create a PKCS12 key and certificate file for import to the Code42 cloud:
    export LC_CTYPE=C
    openssl_pw=$(head /dev/urandom | tr -dc A-Za-z0-9 | head -c 16 ; echo '')
    echo "openssl_pw: ${openssl_pw}" >> secrets.env
    openssl pkcs12 -export -out crashplan.p12 -inkey private_key.pem -in certificate.pem -password pass:${openssl_pw}
    
  6. Clean up files:
     rm ./CA_cert.crt
     rm ./pki_intermediate.csr
     rm ./intermediate.cert.pem
     rm ./certs.json
     rm ./certificate.pem
     rm ./private_key.pem
     rm ./ca_chain.pem
     rm ./crashplanPolicyFile
     unset openssl_pw
    

Step 2: Open your firewall to the Code42 cloud

Implement firewall rules to open an inbound port at your Vault server that allows requests from the Code42 cloud. This allows the Code42 cloud to access keys in your Vault so they can be used for encryption and decryption.

Specific IPs
To obtain specific IPs for the Code42 cloud, contact our Customer Champions for support.

 

Step 3: Configure the Code42 cloud to work with your Vault

The crashplan.p12 file created at the end of Step 1 is a PKCS12 certificate (also called a PFX or P12 file) that identifies your Code42 cloud organization to your Vault server.

Provide the file and its password to the Code42 cloud by following the instructions for migrating keys to a new keystore.

The maximum file size is 5 MB.

Vault best practices

We recommend the following best practices for configuring Vault. For more information, see Vault's Production Hardening guide. 

Use a tested and trusted backend

Vault is compatible with different kinds of storage backends. Choose a storage backend that fits your production needs. Consul is a backend developed by HashiCorp that can function as both a backend for storing data and also service discovery in a multi-cluster setup of Vault. DynamoDB is also widely-used because it supports high availability mode while providing persistent data for Vault.

Run in high availability mode

High availability mode (HA) requires multiple Vault nodes deployed as members of the same cluster. This ensures that when the active node goes offline, the secondary node can continue to respond to API calls. Certain storage backends do not support an HA deployment, so it is important to ensure this is considered when choosing a backend. Some storage backends that support HA include Consul, DynamoDBEtcd, FoundationDB, and Zookeeper.

Do not run in development mode

You can run Vault in development mode with the following command:  vault server -dev

Never use this command to launch Vault in production environments. Launch Vault from a script like init.d or systemd as found in a Linux distribution (distro). You should also create a Vault user and group, and preferably a volume mount that only Vault can read and write to.

Always use TLS

Vault should always be used with Transport Layer Security (TLS) in production. Most high availability production environments would normally have a load-balancer or reverse proxy route traffic to the Vault nodes. It is important to ensure that this traffic is not terminated on these devices. There should end-to-end TLS communication from Code42 authorities to the load-balancer to Vault nodes.

Run as a single tenant

Run Vault as a single tenant on a machine. This reduces the risk of compromising the Vault service and exposing the keys because there is no other process on the machine that can be compromised.

Configure firewall rules

Vault listens on ports 8200 and 8201. We recommend that in a production deployment you use a local firewall to control all traffic to Vault. In cloud provider environments, use a security group or firewall rule to achieve the same objective.

Enable auditing 

Enable auditing to provide a record of Vault operations. You can send audit logs to a different destination or other system processes like syslog.

Consider your upgrade procedure

If you use automated deployments for upgrading applications, it is important to consider how you upgrade Vault and your storage backends. Choose a backend that allows for persistent data during automated deployment upgrades. DynamoDB and Google Cloud Spanner both ensure persistency during a rolling upgrade.

  • Was this article helpful?