Gerenciando usuários com fantoches ou ldap?

3

Existem vários respostas que efetivamente dizem que o ldap deve ser usado em vez do fantoche para gerenciar usuários reais. Estou inclinado a concordar com base em uma perspectiva de escala. A integração de novos membros da equipe deve ser feita por equipes de suporte, não por administradores que adicionam novos recursos de usuário.

No entanto, o gerenciamento de chaves ssh e chaves autorizadas (junto com o acesso sudo e arquivos de configuração do usuário) parece um trabalho perfeito para o fantoche.

Qual é o modo padrão de gerenciar chaves e configurações por usuário? O fantoche pode aumentar o ldap aqui? O que acontece se um funcionário se tornar desonesto e precisarmos revogar sua chave de 1000 arquivos diferentes de authorized_keys?

    
por Josh Smeaton 21.03.2013 / 04:12

3 respostas

5

Eu não concordo com Graig Watson.

Criar cópias de contas significa que você tem problemas para mantê-las em sincronia. Ter uma única fonte para informações de autenticação elimina muitas complicações e o LDAP é muito mais fácil de integrar em outros serviços (web, correio, etc.).

Em termos de acesso ao sudo - se você configurar seus sudoers com base em grupos e não em indivíduos, o acesso às instalações pode ser facilmente controlado via LDAP. Requer mais planejamento futuro - mas é muito mais fácil de gerenciar a longo prazo - você gerencia a segurança política e não arquivos de dados.

Tornar as chaves ssh disponíveis em outras máquinas é melhor administrado usando algum tipo de sistema de arquivos de rede - pode ser NF / Samba, mas os sistemas de arquivos replicados ou compartilhados fornecem o mesmo objetivo (com diferentes efeitos colaterais).

O primeiro passo deve ser sempre definir seu modelo de segurança - permitindo que as configurações locais forneçam um enorme espaço para minar esse modelo.

    
por 21.03.2013 / 13:03
1

Eu diria que o Puppet é uma solução melhor que o LDAP, já que ele não tem SPoF (logins são locais, mas gerenciados centralmente).

Em qualquer caso, para o cenário "usuário não autorizado", você pode usar o recurso ssh_authorized_key Puppet e ensure => absent em sua chave. Em seguida, use o Mcollective / cron para preencher isso.

Consulte o documento: link

A dificuldade é fazer com que o Puppet gerencie um arquivo nos diretórios home dos usuários (que podem ou não existir). Você poderia atenuar isso personalizando o local do arquivo authorized_keys na configuração do SSH (por exemplo, /var/lib/ssh/authorized_keys/%u ).

    
por 21.03.2013 / 12:10
1

Estou muito satisfeito com: link

Ele contém tudo o que você precisa - usuários, sudoers, chaves ssh e até mesmo configurações de selinux.

    
por 11.09.2014 / 23:34