O Puppet ou o Chef é adequado para gerenciar configurações muito básicas do servidor em um ambiente de vários locatários?

Isso se refere a ambientes com vários locatários, como uma pequena empresa de hospedagem.

O Puppet (ou similar) é uma tecnologia adequada para cuidar de mudanças de massa básicas, porém críticas? Por exemplo:

• Atualizando resolvedores de DNS (resolv.conf)
• Configurando chaves SSH
• Atualizando a configuração NTP
• Configurando o snmpd
• Implementando scripts de monitoramento, como extensões SNMP Perl ou scripts Nagios

Minhas preocupações são sobre segurança e invasão:

1. Não quero que nenhum servidor possa ver nenhuma configuração que não deveria
2. Estou preocupado que um mestre de marionetes possa estar vulnerável a ataques de um servidor comprometido
3. Não quero que o Puppet faça alterações que não devam ou reverta as alterações manuais feitas no servidor.

Devo ressaltar isso dizendo que nunca usei o Puppet na produção, só tive uma rápida brincadeira em um laboratório de teste, então é possível que eu esteja pensando nisso da maneira errada!

Tente Ansible (ansible.cc). Pode ser que seja para você. Não há nenhum agente em execução nos seus clientes. Está crescendo muito rápido.

Outra alternativa muito boa é o Salt Stack.

Ansible e Salt são fáceis de entender, você pode usá-los como uma ferramenta de linha de comando, se desejar, como shell distribuído.

Sim, isso é certamente possível. Decidir se você deve ou não fazê-lo é com você.

Em relação às suas consultas:

1) justo o suficiente. O tráfego é baseado em SSL, portanto, o gerenciamento de certificados é importante. Também não confie em nenhum "fato" que o cliente forneça relacionado à sua identidade, pois eles podem ser alterados pelo cliente. Você deseja confiar no certificado SSL do cliente para fornecer a autenticação de quem é o servidor. Para ser honesto, se você estiver usando coisas como hiera corretamente e evitando enormes blocos de if com base em nome de host em seu código (o que você realmente deveria), você ficará bem.

2) Não deveria ser, supondo que você o mantenha atualizado. Configurado corretamente, há apenas um pequeno vetor para o puppetmaster ser atacado pelos clientes. Dito isto, os efeitos, se comprometidos, são grandes, portanto, tome cuidado para travá-lo.

3) Esse é realmente um problema de teste e implantação. Se você tiver um código de fantoche sólido, ele não estragará seus arquivos. Demora um pouco para resolver isso, mas para o básico (como você precisa) não demora muito.

O Puppet (ou similar) é uma tecnologia adequada para cuidar de mudanças de massa básicas, porém críticas?

Sim, pode ser usado dessa maneira. Eu uso isso para dar suporte a sistemas de clientes externos.

Não quero que nenhum servidor possa ver nenhuma configuração que não deveria

Se você estiver usando fantoches, não deverá ativar a assinatura automática. A assinatura automática permite que os hosts solicitem automaticamente um certificado. Sua configuração e permissões quase certamente serão vinculadas diretamente à CN no certificado. Você não quer que um computador aleatório fique online e seja capaz de afirmar que eles são realmente o sistema com todo o material secreto de alta segurança.

Se você é realmente paranóico, pode ajustar as configurações do servidor de arquivos fantoches para criar compartilhamentos que apenas alguns sistemas podem acessar. O acesso ao servidor de arquivos é baseado nos certificados.

Não quero que o Puppet faça alterações que não devam ou reverta as alterações manuais feitas no servidor.

Existem algumas abordagens diferentes para permitir mudanças locais.

Um método que eu frequentemente uso está abaixo. Basicamente, se você passar uma lista para a source, o boneco tenta cada item da lista. Então, adiciono o primeiro item da lista para apontar para um arquivo local.

  file { '/etc/ssh/sshd_config':
    ensure => present,
    source => ["/etc/ssh/sshd_config_local",
               "puppet:///modules/ssh/$ssh_config_file"],
    ...
  }

Outra opção seria fazer uso de links simbólicos. Se alguém quiser usar a versão fantoche, vinculará a versão fantoche de um arquivo. Se eles desejam manter sua configuração localmente, eles não criam um link simbólico.

  file { '/etc/ssh/sshd_config_puppet':
    ensure => present,
    source => "puppet:///modules/ssh/$ssh_config_file",
    ...
  }

A outra possibilidade é usar augeas para fazer alterações no nível da linha, em vez de alterar arquivos inteiros. Seja muito conservador sobre o que muda.

3> Não há desfazer automático no Puppet ou em nenhuma dessas ferramentas. Você precisa escrever um código explícito para desfazer. Além disso, você pode pesquisar o recurso de ambientes do fantoche, ter um laboratório de testes onde o novo código é testado (poderia ser VMs) e usar a revisão de código.

Não quero que o Puppet faça alterações que não devam ou reverta as alterações manuais feitas no servidor.

Para arquivos de configuração criados usando o tipo de arquivo Puppets, isso pode ser alcançado configurando:

replace => false,

Eu uso isso para gerar alguns arquivos de configuração na primeira vez que um aplicativo é implantado em um servidor, mas qualquer edição desse arquivo de configuração não será substituída pelo Puppet.

No entanto, isso contraria a filosofia do Puppet de ser um script de implantação idempotente.

Pode ser melhor, se você puder, ter arquivos editáveis ​​pelo administrador separados que não sejam gerenciados pelo fantoche, incluídos nos arquivos gerenciados pelo fantoche.

O Puppet funciona melhor para muitos servidores com configuração idêntica. Por exemplo, você escreve toda a configuração de um servidor da web compartilhado fornecido pela sua empresa e cria N instâncias desse servidor. Depois de fazer alterações em todas as instâncias de uma só vez (por exemplo, você descobre que é necessário alterar o AllowOverride para todos os hosts virtuais apache) será realmente fácil. Você também poderá armazenar todas as informações de configuração em um único local e tê-las sob controle de versão. No caso perfeito, você poderá lidar com uma falha de hardware jogando fora o host quebrado, substituindo-o por um novo, definindo o mesmo nome de host e assinando o certificado necessário. Tudo o resto poderia ser feito por Puppet.

Mas se você acabar com quase nenhum compartilhamento de configuração entre dois hosts, usar o fantoche pode ser menos produtivo do que fazer a configuração manualmente. Também gerenciar metade da configuração do servidor com o fantoche e a outra metade manualmente pode não fazer muito sentido.

Resumo : Se você pode criar uma configuração uniforme e estruturada para os hosts que você gerenciará, o Puppet é seu melhor amigo, mas se você precisar lidar com cada serviço (host, host virtual, banco de dados), especialmente o Puppet não adicionará muito valor.