Skip to content

Namespaced Key Pairs

Jeff Felchner edited this page Mar 6, 2023 · 4 revisions

On larger projects and those with multiple developers, it may not be desirable for all of the same people who have access to settings encrypted in development or test to also have access to those encrypted for staging or production.

Especially when considering production, those live API keys and other pieces of information can be incredibly sensitive.

On the other side, if you have settings for your local machine which you would like to keep from prying eyes for some reason, encrypting those settings with the Chamber project key doesn't help you very much.

So what are we to do?

Chamber provides you a way of encrypting and decrypting your settings based on the namespace it's located in. In other words, you can have a key for development, test, staging and production.

Wow Jeff, that sounds like a lot. And it sounds kind of complicated.

I know it can sound that way, but let's walk through a few scenarios and you'll see how Chamber makes it easy.

Example: Encrypting Production Settings

The first step for any of your namespaced key adventures is to generate the key. This is done the same way that you've always done it: chamber init. The difference is that you pass in the namespaces option with the namespaces you'd like to create a key for.

chamber init --namespaces="production"

This will generate some new files that should be very familiar to you:

  • .chamber.production.pem
  • .chamber.production.enc
  • .chamber.production.enc.pass
  • .chamber.production.pub.pem

All of these files follow the same conventions that you learned in the encryption section.

However, now that these files exist, if you create a new setting such as:

# settings.yml

# Snip...

production:
  smtp:
    _secure_host: 'https://smtp.example.com'

When you run chamber secure, Chamber will see that it's part of the production namespace and use .chamber.production.pub.pem instead of .chamber.pub.pem to encrypt it.

Similarly, when you access Chamber.dig!('smtp', 'host') in your app, if it's running in production, Chamber will use .chamber.production.pem to decrypt it, (whereas if it's running in another environment, it'll use .chamber.pem).

Example: Encrypting Local Settings

This works for as many namespaces as you'd like. For example, you may want to check in your local settings, but keep the rest of the team from being able to see them.

In order to do that, you'd just run:

chamber init --namespaces="$(hostname)"

You'd check in the public key and then make sure the private key was for you and you alone.

If you add a setting:

# settings.yml

# Snip...

yourhostname:
  slack:
    _secure_notification_url: 'https://myteam.slack.com/mysupersecrethooktoken'

Then after a chamber secure, only you would be able to read it.

What About Already Encrypted Settings?

If you're adding namespaced keys to an existing project which may already have settings that have been encrypted by the default key, you may think you'd have a problem.

Example

# settings.yml

# Snip...

production:
  smtp:
    # This value was secured with .chamber.pub.pem and NOT .chamber.production.pub.pem
    _secure_host: JL5hAVux4TERpv49QPWxy9H0VC2Rnk7V8/e8+1XOwPcXcoH/a7Lh253UY/v9m8nI/Onb+ZG9nZ082J4M/BmLa+f7jwMEwufIqbUhUah9eKIW8xcxlppBYpl7JVGf2HJF5TfCN44gMQNgGNzboCQXKqRyeGFm4u772Sg9V2gEx/q7qJ6F4jg7v/cltCFLmJfXA2SHA5Dai4p9L4IvMVVJGm34k5j7KOegNqpVWs2RY99cagjPuzc9VM2XSUsXgqcUJdmH8YtPW8Kqkyg0oYlRh6VQWABlWXwTZz74QjTTjqtqfoELIoFTMBDh+cCvuUTAE5m06LhlqauVrB4UnBsd5g==

Once you generate chamber init --namespaces="production" and Chamber starts using .chamber.production.pem, the above decyption will fail right? Nope.

Chamber will always fall back to the default key if the namespaced key fails to decrypt the value.

Re-Secure

But what about if you don't want the default key to work any more. After all, the point of having a namespaced key is so that those without that key can no longer see what the values are. If the existing values have already been encrypted with the default key, then anyone with the default key can still see them.

For that you will need to re-secure your settings.

Clone this wiki locally