Chef: sacos de dados criptografados, protegendo a chave de criptografia

Question

Quando você está usando o recurso de pacote de dados criptografados para o Chef, como você implementa a chave em muitos servidores? Se você colocá-lo em uma receita, qualquer um que tenha acesso a qualquer um dos chefs ou clientes chefes pode puxar a chave e potencialmente descriptografar qualquer um dos databags.

Como você faz para garantir que a chave esteja nas máquinas que precisam, mas também protegida de quem estiver bisbilhotando?

    

Answer 1

Infelizmente, não há muito o que fazer, pois a chave precisa estar em algum lugar no nó Chef em texto simples. Se alguém tiver shell ou acesso local à caixa, talvez seja possível que eles leiam a (s) chave (s).

Para atenuar um pouco, adiciono o seguinte ao meu basenode (ou seja, uma receita ou função que é comum a todos os nós):

directory "/etc/chef/keys" do
  mode 0700
  owner "root"
  group "root"
end

e qualquer mecanismo de distribuição de chaves que você tenha coloca chaves nesse local. As permissões e a propriedade impedem a leitura das chaves se alguém esquecer de colocar as permissões corretas em um arquivo-chave.

Como eu vejo, os pacotes de dados criptografados são mais para proteger o material chave de ser legível em um sistema de controle de origem, e menos como um recurso de segurança nos próprios nós do Chef.

    

Answer 2

Meus EDBs são separados por:

• ambiente
• role

Enviamos todas as chaves com um sufixo especial para cada nova instância do EC2 à medida que as inicializamos e, em seguida, removemos todas as chaves que não foram usadas por qualquer das receitas na lista de execução no final da primeira vez que estará certo quando a instância começar.)

Todos os arquivos são enviados como proprietário e grupo "root" e com apenas permissões de leitura.

Toda receita que usa um EDB gera o nome do EDB e o nome do arquivo de chave no tempo de execução da receita concatenando 'edb_' + o ambiente dos nós + receita / nome específico do item + '.key' e depois procura a chave por este nome. (Se não existir, isso gera uma exceção por padrão).

Assim, para o nosso servidor couchdb, executando uma função chamada 'couch', para obter as credenciais que estamos usando para o (s) usuário (s) admins no ambiente de desenvolvimento, a receita procura por uma chave chamada 'edb_dev_couch. chave '

Em seguida, pesquise um pacote de dados chamado 'edb_dev' para um item chamado 'couch_credentials'.

Para gerenciar chaves, atualmente estou usando a abordagem simples de:

• faça o upload de todas as chaves EDB por meio do script de bootstrap e anexe '_x' aos nomes das chaves
• Ter cada receita que usa uma aparência EDB no diretório de chaves para a chave que precisa.
• se a chave existir com um sufixo "_x", renomeie a chave para remover o sufixo "_x".
• adicione uma receita no final de cada run_list que exclua todas as chaves com um sufixo '_x'

Com sorte, isso limita o tempo em que as chaves fora do escopo de um único nó são suscetíveis até que a máquina seja inicializada e tenha a primeira execução de chef_client.

Esta é a nossa primeira rodada de testes de como proteger as chaves, mas até o momento atende às nossas necessidades atuais, pois impede que um servidor de desenvolvimento possa acessar imediatamente quaisquer outras credenciais de servidores armazenadas em um EDB.

Para manter uma receita no final de cada lista de execução, eu uso um trabalho exec de faca que garante que essa receita delete_keys seja exatamente a última receita em todos os nós.

    

Answer 3

Minhas chaves são incorporadas nas AMIs que usamos ou nas imagens que usamos. Eu não faço isso como parte do bootstrap, pois os dados não são seguros. Normalmente, você pode ver dados em registros e, caso não seja cuidadoso.