Skip to content

Re Securing

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

There are times in which you will want to rotate your private keys. Maybe your private key was compromised in a data breach or maybe an employee that had access to it is no longer trusted. Maybe you're switching to namespaced private keys and need to re-encrypt values that were encrypted with the original shared key. How do you do it?

WARNING: If a value has been committed to the repo which you're trying to hide from someone who has the default private key, there's nothing you can do. They can always check out a commit before you introduced the namespaced key and see what the values were at that point.

What you need to do is generate something new (new password, new API key, etc) and then encrypt that new value with the namespaced key.

But let's say you know what you're doing and you want all of your existing values to be decryptable only a new private key.

That's relatively easy. All you have to do is re-secure your settings by:

  1. Running chamber unsecure
  2. Generating your new keys by reinitializing or by generating namespaced key pairs (or both)
  3. Running the proper chamber secure commands

This step will decrypt everything and then re-encrypt everything. If you have namespaced keys, such as .chamber.production.pub.pem, any production values will be re-encrypted using that key. From that point on, the old keys will no longer be able to decrypt your settings.

If you're using a cloud integration, don't forget to re-push your new private key information.

Clone this wiki locally