Como gerar arquivos sudoers customizados no fantoche, dependendo do ambiente para o qual eles estão implementados?

3

os sysadmins estão presentes nos arquivos sudoers de todos os ambientes, mas outros sudoers não estão. Ambientes diferentes, todos têm sudoers ligeiramente diferentes. Na maioria das vezes, 90% dos usuários são iguais e 10% variam, portanto, não podemos ter apenas um arquivo sudoers para tudo.

Neste momento, estamos usando fantoches com 10 arquivos diferentes com nomes como sudoers.production1, sudoers.production2, sudoers.production3, sudoers.testing1, sudoers.staging1 e assim por diante.

O Puppet escolhe o arquivo a ser implantado com base no domínio $ do servidor (ex: dbserver.staging1.acme.com) ou $ hardwaremodel. Funciona bem, mas é um pesadelo manter muitos arquivos.

Gostaria de gerar automaticamente os arquivos sudoers com base no domínio do servidor e ter apenas um arquivo grande com todas as permissões de sudoers para todos os usuários e todos os ambientes. Algo que parece:

User_Alias ADMINS = abe, bob, carol, dave

case $domain {
 "staging1.acme.com" {
    #add dev1,dev2,tester1,tester2 to sudoers file 
  }
 "testing2.acme.com" {
    #add tester1, tester3, tester4 to sudoers file
  }    

Qual é a melhor maneira de fazer isso? Sugestões de alternativas são bem vindas. Eu apreciaria qualquer dica.

Atualização 1:

Por razões de segurança, preferimos não concatenar um monte de arquivos de uma pasta localizada em um cliente fantoche no caso de alguém colocar um arquivo lá (maliciosamente ou não) e quebrar o arquivo combinado ou inserir algo nele.

O mais importante, para usabilidade, nós gostaríamos de manter o número de arquivos relacionados a sudoers (fragmentados ou completos) no servidor de fantoches para 3 (prod / stage / test) ou preferivelmente 1 arquivo. esse arquivo (de alguma forma) geraria arquivos sudoers no servidor de fantoches e enviaria um arquivo personalizado para cada cliente de fantoches.

O objetivo disto seria procurar apenas por um nome de usuário em um único arquivo e removê-lo mais rápido do que fazê-lo em 11 arquivos. Ao adicionar um usuário a vários ambientes, ele não será tão rápido, mas apenas um arquivo precisará ser aberto e examinado, reduzindo bastante as chances de uma omissão.

nossa versão do Sudo é 1.6.9p8, portanto não podemos usar a pasta /sudoers.d, apenas um arquivo sudoers.

Update2:

Eu estive no google e acabei de descobrir isso, que passei a última hora observando:

link

Não tenho certeza, mas parece que isso pode funcionar. Alguém já usou ou ouviu falar sobre isso?

    
por gozu 04.12.2012 / 18:51

3 respostas

9

Qual versão do sudo? Sua versão do sudo suporta o uso da opção #includedir para dividir as coisas em um diretório de fragmentos /etc/sudoers.d/ ?

Em caso afirmativo, sugiro que você use essa funcionalidade para criar sua configuração.

Envie seu arquivo de configuração principal para /etc/sudoers , que inclui todas as configurações comuns a todos os hosts controlados por você. Em seguida, faça com que a configuração específica da função seja descartada em um arquivo em /etc/sudoers.d/ .

Cada seção de classe ou marionete é responsável por atualizar a pequena parte da configuração do sudo diretamente relacionada a essa classe.

    
por 04.12.2012 / 18:59
3

veja os recursos virtuais e perceba - link - isso faz exatamente isso - em alguns sistemas que você "percebe" o recurso e em alguns você não.

    
por 05.12.2012 / 00:11
2

Você pode fazer usando modelos de marionete ... Configuração específica do site com um pequeno trecho / variável ruby para o usuário que você precisa. (Vou postar um exemplo depois)

A maneira tradicional de lidar com isso é usando definições de grupo em vez de usuários nomeados em /etc/sudoers . Pode ser menos complicado gerenciar.

    
por 04.12.2012 / 18:59