Quando você está usando o recurso de bolsa de dados criptografados do Chef, como implanta a chave em muitos servidores? Se você colocá-lo em uma receita, qualquer pessoa que tenha acesso a qualquer um dos servidores ou clientes chef pode puxar a chave e potencialmente descriptografar qualquer um dos bancos de dados.
Como você garante que a chave esteja nas máquinas que precisam, mas também a salvo de quem bisbilhotar?
Respostas:
Infelizmente, não há muito o que fazer, pois a chave precisa estar em algum lugar do nó Chef em texto sem formatação. Se alguém tiver acesso local ou shell à caixa, talvez seja possível que eles leiam a (s) chave (s).
Para atenuar um pouco as coisas, adiciono o seguinte ao meu código de base (ou seja, alguma receita ou função 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ê possui coloca as 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 de chaves.
A meu ver, os pacotes de dados criptografados são mais para impedir que o material principal seja legível em um sistema de controle de origem e menos como um recurso de segurança nos próprios nós do Chef.
Meus EDBs são separados por:
Carregamos todas as chaves com um sufixo especial em todas as novas instâncias do EC2 à medida que as inicializamos e, em seguida, removemos todas as chaves que não foram usadas por nenhuma das receitas da run_list no final da primeira vez que o chef-cliente é executado (que será logo que a instância inicia.)
Todos os arquivos são carregados 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, em seguida, procura a chave com esse nome . (Se não existir, isso gera uma exceção por padrão.)
Portanto, para o nosso servidor couchdb, executando uma função chamada 'couch', para obter as credenciais que estamos usando para o (s) usuário (s) do administrador no ambiente dev, a receita procura uma chave chamada 'edb_dev_couch.key'
Em seguida, ele procura em um pacote de dados chamado 'edb_dev' um item chamado 'couch_credentials'.
Para gerenciar chaves, atualmente estou usando a abordagem simples de:
Felizmente, 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 do chef_client.
Esta é a nossa primeira rodada de testes de como proteger as chaves, mas, até o momento, atende às nossas necessidades atuais, pois evita que um servidor de desenvolvimento root consiga acessar imediatamente quaisquer outras credenciais de servidor armazenadas em um EDB.
Para manter uma receita no final de cada lista de execução, eu uso um trabalho de exec de faca que garante que esta receita delete_keys seja exatamente a última receita em cada nó.
Minhas chaves estão inseridas nas AMIs que usamos ou nas imagens que usamos. Não faço isso como parte do bootstrap, pois esses dados não são seguros. Normalmente, você pode ver dados nos logs e outros, se não tomar cuidado.