-
-
Notifications
You must be signed in to change notification settings - Fork 25
Re Securing
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:
- Running
chamber unsecure
- Generating your new keys by reinitializing or by generating namespaced key pairs (or both)
- 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.
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