-
-
Notifications
You must be signed in to change notification settings - Fork 25
Namespaced Key Pairs
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.
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
).
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.
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.
# 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.
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.
Copyright ©2023
- Release News
- Gem Comparison
- 12-Factor App Rebuttal
- Environment Variable Problems
- Installation
- Basics
- Defining Settings
- Accessing Settings
- Verifying Settings
- Namespaces
- Environment Variables
- Integrations
- Encryption
- Advanced Usage
- Command Line Reference