blob: 85877c71b75c087555ffe399f7080288ad0f03ba (
plain) (
blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
|
=== Storing Encrypted Credentials in Source Control
The Rails `credentials` commands provide access to encrypted credentials,
so you can safely store access tokens, database passwords, and the like
safely inside the app without relying on a mess of ENVs.
This also allows for atomic deploys: no need to coordinate key changes
to get everything working as the keys are shipped with the code.
=== Setup
Applications after Rails 5.2 automatically have a basic credentials file generated
that just contains the secret_key_base used by MessageVerifiers/MessageEncryptors, like the ones
signing and encrypting cookies.
For applications created prior to Rails 5.2, we'll automatically generate a new
credentials file in `config/credentials.yml.enc` the first time you run `bin/rails credentials:edit`.
If you didn't have a master key saved in `config/master.key`, that'll be created too.
Don't lose this master key! Put it in a password manager your team can access.
Should you lose it no one, including you, will be able to access any encrypted
credentials.
Don't commit the key! Add `config/master.key` to your source control's
ignore file. If you use Git, Rails handles this for you.
Rails also looks for the master key in `ENV["RAILS_MASTER_KEY"]`, if that's easier to manage.
You could prepend that to your server's start command like this:
RAILS_MASTER_KEY="very-secret-and-secure" server.start
=== Editing Credentials
This will open a temporary file in `$EDITOR` with the decrypted contents to edit
the encrypted credentials.
When the temporary file is next saved the contents are encrypted and written to
`config/credentials.yml.enc` while the file itself is destroyed to prevent credentials
from leaking.
|
