Migrating critical keys from Lockr to Pantheon Secrets

When your website depends on a billion (ok, maybe a million) dependencies to function securely, and, um, dependably, a shutdown notice from a vendor, while not unusual, can cause the heart to skip a beat or two if your data relies on that vendor. That’s what happened last week when Lockr announced that the service will end on November 30.

The two-month advance warning doesn’t require all hands on deck, but yes, your secrets or keys will go away soon, and in our case below, all the encrypted data, which is almost all of the data, will no longer be decryptable if no action is taken.

Fortunately the timing of Lockr’s announcement happened right as Pantheon rolled out their Secrets feature.

For our client Ohio Legal Help, a Drupal website, we encrypt all webform data with a recipe that includes the Lockr service, the Lockr, Key, Encrypt and Webform Encrypt modules. Lockr holds the key without which we can no longer decrypt existing data.

Here’s what we did to replace Lockr with Patheon Secrets:

Requirements

1. Pantheon’s Terminus CLI

2. Pantheon’s Terminus Secrets Manager Plugin

3. The Pantheon Secrets module for Drupal

4. Drush

After you’ve installed all of that, complete the following steps:

Get the keys

Get the Live and Dev keys. Lockr integrates with Pantheon to automatically create a distinct Live key, and the other environments (Test, Dev and Multidevs) share a Dev key.

terminus remote:drush [site].[env] key:value-get [webform_encryption] --base64

Replace [site] with your website’s machine name. Replace [env] with Live or Dev. Here, [webform_encryption] is the name of our key. We need the base64 flag because we can’t store the encryption key in its native binary.

Repeat this for both keys.

Add the keys as secrets

First set the default key for all environments. You’ll need to replace the bracketed strings with your own values in the commands below.

terminus secret:site:set [mysite] [webform_encryption_pantheon] [your_dev_key] --scope=web --type=runtime

Now set an override for the live environment. The Pantheon Secrets module will handle delivering the correct key.

terminus secret:site:set [mysite].live [webform_encryption_pantheon] [your_live_key] --scope=web --type=runtime

There are other options for --scope and --type, but this is what you need to make the secret available to the website. We added the _pantheon suffix arbitrarily. You don’t need it, but your secret will not sync if its name matches an existing key name.

Sync the secrets and set up your replacement keys

Log into your site and go to the Sync all Pantheon Secrets tab at /admin/config/system/keys. Click the “Sync Keys” button. 

Go to the Keys tab and edit your new key. You’ll notice that the Key provider is Pantheon, which comes from the Pantheon Secrets module. In our case, we needed to change the Type to encryption and the Length to 256, and check Base64 encoded. You can also rename the key. Save your changes.

The next step for us was to edit the existing Encryption profile, which is used by the Webform Encrypt module, and set it to use the new key. Don’t change the Encryption Method. This happens at admin/config/system/encryption/profiles/manage/your_profile_name

Testing

That’s it! To test, and before you disconnect from Lockr, change the profile back and forth from the old Lockr provided key to the new Secrets provided key. Make sure you can do the same stuff with both providers. In our case “stuff” means creating a webform submission with one key provider and then editing it with the other provider.

A few notes

We exclude key and encrypt configuration using the Config Ignore module. But for local development I use a Lando split from the Config Split module, and configure an Environment key provider. I set the ENV variable in my .lando.local.yml file, which is ignored by Git. This saves me time – I don’t need to set up the configuration every time I pull a database. 

Again, replace the bracketed value with your own value

services:
  appserver:
    overrides:
      environment:
        LOCAL_ENCRYPTION_KEY: "[your_local_key]"

You could use the Dev key or a new key here, but whatever you use, be sure to never commit it. If the live key were to ever become public, all the encrypted data would be at risk.

Likewise, be sure to scrub the keys from your clipboard manager, terminal history, scratch files, or wherever else you may have stored them temporarily.