É ruim usar o sudo da Jenkins?

Eu uso o plug - in Publish Over SSH para implantar meus aplicativos Jenkinsem ambientes diferentes. Algumas tarefas de implantação realizam a preparação do ambiente e coisas como parar e reiniciar o serviço do sistema do servidor de aplicativos. Alguns desses comandos exigem sudo.

Estou curioso para saber se pode ser uma má prática de segurança exigir o sudo em trabalhos remotos de publicação e execução Jenkins. Devemos alterar a política de segurança no host de destino para permitir que as funções necessárias sejam executadas sem o sudo?

Não, é realmente uma boa prática de segurança sudo quando você precisa de privilégios de nível superior. Esta é a razão pela qual a maioria das distribuições proíbe o login padrão e realmente o força a sudo sufazê -lo, em vez de apenas digitar su- elas querem incentivá-lo a usar o sudo por seus benefícios de segurança. Existem algumas razões pelas quais:

• Auditoria. Quando você sudo, o sistema mantém um registro de quem sudoou e o comando que eles executaram. Isso adiciona muito forense quando você precisa voltar e descobrir o que aconteceu - atribuir culpas, pegar atividades nefastas ou apenas para fins de solução de problemas (o que diabos aconteceu ontem à noite às 19:00 antes que o servidor fosse AWOL?)

• Regras do Sudo. Só porque um usuário precisa executar algo com privilégios escalados não significa que ele precisa executar tudo com privilégios escalados. Usar su ou adicionar um usuário ao wheel permite que ele faça tudo . No entanto, com o sudo, é possível especificar o que os usuários podem ou não fazer usando Aliases de Comando que permitem o uso de curingas, permitindo regras flexíveis que concedem privilégios aos usuários para usar alguns comandos, mas não outros.

• Endurecimento. É possível desativar o root. Por exemplo, para todos os efeitos, ele não existe e é apenas útil / utilizável no modo de usuário único - exigindo a reinicialização de um servidor (e a única razão pela qual isso é permitido é a recuperação de senha). sudo sunão funciona mais. Isso é feito configurando o shell do root como / bin / nologin. que é uma ótima maneira de evitar muitas vulnerabilidades de escalação raiz. Obviamente, isso pressupõe que você esteja usando corretamente o marcador acima (e ainda é possível conceder todas as permissões a um usuário administrador específico, embora isso prejudique sua postura de segurança).

Obviamente, essas coisas são apenas parte do seu modelo de segurança. Por exemplo, a menos que você não tenha usuários com privilégios administrativos completos (e às vezes até mesmo), seu usuário poderá (provavelmente conseguir) excluir logs e histórico - a menos que você use um servidor de log e o syslog para enviar os logs para fora da caixa. Então não há como colocar o gato de volta na sacola. Obviamente, se você usar uma estrutura de diretórios de autenticação central, isso voltará ao jogo: se eu comprometer uma conta, ela será comprometida em todos os servidores da organização - incluindo provavelmente o servidor de log.

Em suma, a segurança é complicada, mas o sudo é uma ótima ferramenta para arquitetar um ambiente seguro e mais pessoas devem usá-lo em sua extensão máxima.

Se você permite sudoacesso remoto ou remoto a algo que SUID rootpossui uma superfície de ataque bastante semelhante. Eu manteria sudoa cadeia porque permite limitar os comandos facilmente e possui registros que serão vitais se você precisar auditar as coisas posteriormente. sudotambém tem uma história muito mais longa na produção. Fazer outra coisa terá menos história e maiores mudanças de surpresas desagradáveis.

Existem outras coisas que você pode fazer para tornar isso mais seguro:

• apertar ssh
• permite apenas os comandos de reinicialização para alguns usuários específicos, incluindo um para o jenkins
• só permite logins para usuários específicos de todos os IPs internos ou apenas IPs de Jenkins e Jump Box
• armazene logs em caixas remotas para que não possam ser prejudicados