From 11660945696155c86a05260795e1a0afce0d291d Mon Sep 17 00:00:00 2001 From: Kasper Timm Hansen Date: Thu, 23 Feb 2017 15:01:02 +0100 Subject: Add encrypted secrets (#28038) --- railties/lib/rails/commands/secrets/USAGE | 52 +++++++++++++++++++++++++++++++ 1 file changed, 52 insertions(+) create mode 100644 railties/lib/rails/commands/secrets/USAGE (limited to 'railties/lib/rails/commands/secrets/USAGE') diff --git a/railties/lib/rails/commands/secrets/USAGE b/railties/lib/rails/commands/secrets/USAGE new file mode 100644 index 0000000000..4b7deb4e2a --- /dev/null +++ b/railties/lib/rails/commands/secrets/USAGE @@ -0,0 +1,52 @@ +=== Storing Encrypted Secrets in Source Control + +The Rails `secrets` commands helps encrypting secrets to slim a production +environment's `ENV` hash. It's also useful for atomic deploys: no need to +coordinate key changes to get everything working as the keys are shipped +with the code. + +=== Setup + +Run `bin/rails secrets:setup` to opt in and generate the `config/secrets.yml.key` +and `config/secrets.yml.enc` files. + +The latter contains all the keys to be encrypted while the former holds the +encryption key. + +Don't lose the 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 +secrets. +Don't commit the key! Add `config/secrets.yml.key` to your source control's +ignore file. If you use Git, Rails handles this for you. + +Rails also looks for the 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="im-the-master-now-hahaha" server.start + + +The `config/secrets.yml.enc` has much the same format as `config/secrets.yml`: + + production: + secret_key_base: so-secret-very-hidden-wow + payment_processing_gateway_key: much-safe-very-gaedwey-wow + +But that's where the similarities between `secrets.yml` and `secrets.yml.enc` +end, e.g. no keys from `secrets.yml` will be moved to `secrets.yml.enc` and +be encrypted. + +A `shared:` top level key is also supported such that any keys there is merged +into the other environments. + +=== Editing Secrets + +After `bin/rails secrets:setup`, run `bin/rails secrets:edit`. + +That command opens a temporary file in `$EDITOR` with the decrypted contents of +`config/secrets.yml.enc` to edit the encrypted secrets. + +When the temporary file is next saved the contents are encrypted and written to +`config/secrets.yml.enc` while the file itself is destroyed to prevent secrets +from leaking. -- cgit v1.2.3 From 039380e3eeb24ed17f1824183b94638f0cfff747 Mon Sep 17 00:00:00 2001 From: David Heinemeier Hansson Date: Thu, 23 Feb 2017 15:55:15 +0100 Subject: Revert "Add encrypted secrets" (#28127) --- railties/lib/rails/commands/secrets/USAGE | 52 ------------------------------- 1 file changed, 52 deletions(-) delete mode 100644 railties/lib/rails/commands/secrets/USAGE (limited to 'railties/lib/rails/commands/secrets/USAGE') diff --git a/railties/lib/rails/commands/secrets/USAGE b/railties/lib/rails/commands/secrets/USAGE deleted file mode 100644 index 4b7deb4e2a..0000000000 --- a/railties/lib/rails/commands/secrets/USAGE +++ /dev/null @@ -1,52 +0,0 @@ -=== Storing Encrypted Secrets in Source Control - -The Rails `secrets` commands helps encrypting secrets to slim a production -environment's `ENV` hash. It's also useful for atomic deploys: no need to -coordinate key changes to get everything working as the keys are shipped -with the code. - -=== Setup - -Run `bin/rails secrets:setup` to opt in and generate the `config/secrets.yml.key` -and `config/secrets.yml.enc` files. - -The latter contains all the keys to be encrypted while the former holds the -encryption key. - -Don't lose the 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 -secrets. -Don't commit the key! Add `config/secrets.yml.key` to your source control's -ignore file. If you use Git, Rails handles this for you. - -Rails also looks for the 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="im-the-master-now-hahaha" server.start - - -The `config/secrets.yml.enc` has much the same format as `config/secrets.yml`: - - production: - secret_key_base: so-secret-very-hidden-wow - payment_processing_gateway_key: much-safe-very-gaedwey-wow - -But that's where the similarities between `secrets.yml` and `secrets.yml.enc` -end, e.g. no keys from `secrets.yml` will be moved to `secrets.yml.enc` and -be encrypted. - -A `shared:` top level key is also supported such that any keys there is merged -into the other environments. - -=== Editing Secrets - -After `bin/rails secrets:setup`, run `bin/rails secrets:edit`. - -That command opens a temporary file in `$EDITOR` with the decrypted contents of -`config/secrets.yml.enc` to edit the encrypted secrets. - -When the temporary file is next saved the contents are encrypted and written to -`config/secrets.yml.enc` while the file itself is destroyed to prevent secrets -from leaking. -- cgit v1.2.3 From fbee4e3ce37674eb928298490a35d3dfd1921e67 Mon Sep 17 00:00:00 2001 From: Kasper Timm Hansen Date: Thu, 23 Feb 2017 18:15:28 +0100 Subject: Revert "Revert "Add encrypted secrets"" --- railties/lib/rails/commands/secrets/USAGE | 52 +++++++++++++++++++++++++++++++ 1 file changed, 52 insertions(+) create mode 100644 railties/lib/rails/commands/secrets/USAGE (limited to 'railties/lib/rails/commands/secrets/USAGE') diff --git a/railties/lib/rails/commands/secrets/USAGE b/railties/lib/rails/commands/secrets/USAGE new file mode 100644 index 0000000000..4b7deb4e2a --- /dev/null +++ b/railties/lib/rails/commands/secrets/USAGE @@ -0,0 +1,52 @@ +=== Storing Encrypted Secrets in Source Control + +The Rails `secrets` commands helps encrypting secrets to slim a production +environment's `ENV` hash. It's also useful for atomic deploys: no need to +coordinate key changes to get everything working as the keys are shipped +with the code. + +=== Setup + +Run `bin/rails secrets:setup` to opt in and generate the `config/secrets.yml.key` +and `config/secrets.yml.enc` files. + +The latter contains all the keys to be encrypted while the former holds the +encryption key. + +Don't lose the 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 +secrets. +Don't commit the key! Add `config/secrets.yml.key` to your source control's +ignore file. If you use Git, Rails handles this for you. + +Rails also looks for the 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="im-the-master-now-hahaha" server.start + + +The `config/secrets.yml.enc` has much the same format as `config/secrets.yml`: + + production: + secret_key_base: so-secret-very-hidden-wow + payment_processing_gateway_key: much-safe-very-gaedwey-wow + +But that's where the similarities between `secrets.yml` and `secrets.yml.enc` +end, e.g. no keys from `secrets.yml` will be moved to `secrets.yml.enc` and +be encrypted. + +A `shared:` top level key is also supported such that any keys there is merged +into the other environments. + +=== Editing Secrets + +After `bin/rails secrets:setup`, run `bin/rails secrets:edit`. + +That command opens a temporary file in `$EDITOR` with the decrypted contents of +`config/secrets.yml.enc` to edit the encrypted secrets. + +When the temporary file is next saved the contents are encrypted and written to +`config/secrets.yml.enc` while the file itself is destroyed to prevent secrets +from leaking. -- cgit v1.2.3 From b16dcc872bb3c094cf1f1d890bdd302593acbbe8 Mon Sep 17 00:00:00 2001 From: Kasper Timm Hansen Date: Thu, 9 Mar 2017 20:19:58 +0100 Subject: [ci skip] Document read_encrypted_secrets config. Mostly just that it's there. Closes #28193. --- railties/lib/rails/commands/secrets/USAGE | 8 ++++++++ 1 file changed, 8 insertions(+) (limited to 'railties/lib/rails/commands/secrets/USAGE') diff --git a/railties/lib/rails/commands/secrets/USAGE b/railties/lib/rails/commands/secrets/USAGE index 4b7deb4e2a..96e322fe91 100644 --- a/railties/lib/rails/commands/secrets/USAGE +++ b/railties/lib/rails/commands/secrets/USAGE @@ -40,6 +40,14 @@ be encrypted. A `shared:` top level key is also supported such that any keys there is merged into the other environments. +Additionally, Rails won't read encrypted secrets out of the box even if you have +the key. Add this: + + config.read_encrypted_secrets = true + +to the environment you'd like to read encrypted secrets. `bin/rails secrets:setup` +inserts this into the production environment by default. + === Editing Secrets After `bin/rails secrets:setup`, run `bin/rails secrets:edit`. -- cgit v1.2.3