it-swarm-pt.tech

Separe secret_key_base no Rails 5.2?

Acabei de atualizar de 5.1 para 5.2 e estou bastante confuso sobre essa metodologia 'melhor' para armazenar segredos ...

Talvez eu não esteja entendendo, mas parece que agora desenvolvimento e produção foram 'fundidos' em um ÚNICO SECRET_KEY_BASE assim como master.key... isso está correto?

Se não, como eu uso uma chave mestra separada e SECRET_KEY_BASE em desenvolvimento?

E se eu tiver desenvolvedores me ajudando e não quiser que eles saibam minha chave mestra (ou segredos) que eu uso na produção?

8
Tallboy

Rails 5.2 mudou isso um pouco. Para desenvolvimento e testes de desenvolvimento, o secret_key_base é gerado automaticamente, assim você pode simplesmente removê-lo do secrets.yml ou onde quer que ele esteja configurado.

Quanto à produção, existe o arquivo de credenciais que você pode gerar e editar executando Rails credentials:edit. Isso também criará a chave mestra em config/master.key, que é usada apenas para criptografar e descriptografar esse arquivo. Adicione isto a gitignore, para que não seja compartilhado com mais ninguém, o que deve ser feito para compartilhá-lo com os colegas devs.

Se tudo isso soa um pouco tedioso, e é, você pode simplesmente ignorá-lo e fornecer o secret_key_base em ENV. O Rails irá verificar se está presente em ENV["SECRET_KEY_BASE"] antes de reclamar. 

5
tomca32

Existem duas maneiras de acessar secret_key_base:

  1. Rails.application.credentials.secret_key_base
  2. Rails.application.secrets.secret_key_base

Rails 5 tomou o primeiro caminho por padrão.

você pode alterar Rails.application.credentials.secret_key_base by Rails credentials:edit. Para todos os outros ambientes, lembre-se de definir a variável de ambiente Rails_MASTER_KEY como o mesmo conteúdo de config/master.key. o master.key é git ignorado por padrão. Desta forma, usa a mesma chave secreta para todos os ambientes. Se você quiser usar chaves diferentes, você precisa controlar os namespaces por conta própria.

Se você preferir a segunda maneira Rails.application.secrets.secret_key_base. você precisa criar config/secrets.yml:

development:
  secret_key_base: ...
test:
  secret_key_base: ...
production:
  secret_key_base: <%= ENV["SECRET_KEY_BASE"] %>

lembre-se de definir a variável de ambiente SECRET_KEY_BASE na produção. Se o arquivo config/secrets.yml for secreto o suficiente, alterar <%= ENV["SECRET_KEY_BASE"] %> para texto simples é bom.

rake secret pode gerar uma chave secreta aleatória para você.

Eu prefiro o segundo caminho (caminho antigo), por causa do simples.

4
Yi Feng Xie

Eu usei essa joia quando não queria compartilhar a master.key da produção com meus desenvolvedores de amigos, o que eu acho que é exatamente o mesmo propósito do OP.

https://github.com/sinsoku/Rails-env-credentials

Você pode ter uma chave mestra para cada ambiente como abaixo, para que você possa ter uma descrição de qual chave deseja compartilhar com quais desenvolvedores/implantadores.

config/credentials-development.yml.enc
config/credentials-test.yml.enc
config/credentials.yml.enc
master-development.key
master-test.key
master.key

Cada chave será gerada quando você executar algo como:

Rails env_credentials: edit -e development

Se você mudar de uma configuração master.key para essa, um erro que você encontrar será relacionado a config/database.yml, no qual o Rails tenta avaliar todas as informações do ambiente, independentemente do ambiente em que você se encontra. se você comentá-los, o Rails ainda tentará avaliar as partes do erb.)

1
untidyhair