Segurança no Jenkins

Quando a automação vira pesadelo

Wesley Silva

● Gerente Cloud / DevOps na CS SP

● Lindo

● Curioso e Inquieto

● Apaixonado por software livre e de

código aberto

● Sempre envolvido em conversas sobre

tecnologia, colaboração e inovação

● Buscando um jeito de usar TI como

ferramenta para um mundo melhor

Por que eu deveria me preocupar com segurança no Jenkins?

Porque tem muita gente usando.

Muita gente mesmo.Conhece alguma dessas empresas?

Vários projetos legais usam.

Algum destes projetos open source faz parte do seu cotidiano?

Ok, entendi. Mas por que eu deveria ouvir vocês?

Porque não queremos ensinar você.

Não dá. Segurança não é como tabuada.

Segurança não deve ser decorada.

Ela deve ser discutida e construída em

colaboração.

Isso não é uma palestra.

Isso é uma discussão em comunidade, nosso

objetivo é compartilhar e aprender vendo

diferentes pontos de vista.

Vamos nessa?

Cenários mais comuns

#1 - Testes e Deploys Manuais

Sim, amigos, este é um cenário bem comum.

Testes são executados manualmente e o

deploy é feito por uma equipe ou pessoa.

Vamos pular este case. Próximo!

#2 - Mundo Maravilhoso da Amazon

Ahhh, que maravilha! Agora sim.

Temos um Jenkins pegando o código do

GitHub, rodando os testes e fazendo

deploy em instâncias EC2 com

AutoScaling e no RDS.

#3 - O Fantástico Docker

Quem não ama Docker? Eu amo.

É tão fácil usar que queremos fazer tudo no Docker.

O Cenário se parece com o anterior, mas em

contêineres.

Fica bem mais fácil subir a infra assim, não é?

#4 - Só quero se for on-premises

Que pena. Este cenário não parece tão

legal, mas também é comum.

Temos um datacenter com servidores

dedicados, gerenciados pela equipe de

TI.

Vejamos melhor...

Percebem um padrão?

● Tem pessoas desenvolvendo.

● Tem um lugar com código.

● Tem um processo de construção.

● Tem um computador que executa.

● Tem um banco que guarda os dados.

● Tem o Jenkins com acesso a tudo isso.

Que comecem os pesadelos!

Como você passa as credenciais?

DISCUSSÃO:

Seu Jenkins precisa ter acesso aos

serviços que vai usar para fazer deploy.

E aí, como você faz?

Erros mais comuns

Ter executores no Master

O Jenkins é uma ferramenta para

executar comandos. Quando tenho

executores rodando no Master, posso

criar jobs que fazem coisas malignas.

Veja o potencial disso:

Permissões liberadas no Jenkins

Quando não há ACLs bem definidas,

usuários podem fazer praticamente

qualquer coisa no Jenkins. Inclusive criar

um executor no Master e rodar o job dos

slides anteriores.

Plugins inseguros

Não adianta fazer a lição de casa criando

ACLs e deixar plugins inseguros

instalados. Alguns plugins abrem

vulnerabilidades enormes.

Vejamos o exemplo do plugin de deploy

por SSH, bastante utilizado:

Máquina compartilhada

Quando usamos máquinas físicas, geralmente

colocamos mais de um serviço por máquina, para

utilizar melhor o hardware. Se não houver uma

camada de separação, os serviços estarão no mesmo

filesystem. Imagina dividir o quarto com um

Wordpress desatualizado...

Docker com vários contêineresRodar o Jenkins no Docker é fácil. O problema é

quando você tem outros contêineres rodando no

mesmo host.

● Quem administra esses contêineres terá acesso

FULL ao Jenkins

● As vulnerabilidades desses contêineres podem

afetar o Jenkins

Informações em variáveis globais

Cuidado com as credenciais. Lembre-se que as

coisas que ficam em variáveis de ambiente podem

ser acessadas por todos com acesso aos jobs.

Lembram do nosso job maligno?

Vamos adicionar uma coisinha...

API Keys no log ou código

Sabemos que se a pessoa tem acesso ao Jenkins,

ela consegue ver os repositórios que tem

credenciais salvas ou chaves de acesso.

Um problema que tem causado prejuízos

globalmente é a chave AWS comitada no código

por engano.

Possíveis impactos

Riscos de TI

● Conta AWS/GitHub/etc

● Servidores

● Bancos de dados

● Domínio do Active Directory

Riscos ao Negócio

● Reputação e marca

● Prejuízos financeiros

● Dados de clientes

● Botnets

Corrigindo as coisas(ou pelo menos tentando)

Ter executores no Master

● Não permita que o Master tenha executores.

Jobs devem rodar em slaves.

● Tenha slaves especializados que não sejam

capazes de fazer muito além do que deveriam,

com regras restritas de firewall e monitoria.

Permissões liberadas no Jenkins

● Tenha uma matriz de usuários com o

mínimo de acessos possível liberados

para fazer o trabalho.

Plugins inseguros

● Leia o changelog dos plugins e não utilize

aqueles que não recebem atualizações

constantes.

● Teste, teste, teste e teste novamente.

Máquina compartilhada

● Evite colocar o Jenkins junto com outros serviços,

principalmente quando faz deploys em produção.

● A máquina que roda o Jenkins deve passar por

um processo de hardening.

Docker com vários contêineres

● Quando o Jenkins rodar em um Docker com

outros contêineres, tenha em mente que uma

matriz com cada serviço em execução no host

deve ser elaborada. As falhas desses serviços são

falhas no Jenkins, tenha isso sempre em mente.

Informações em variáveis globais

● Todos os jobs têm acesso às variáveis

de ambiente. Evite passar

informações sensíveis desta forma.

API Keys no log ou código

● Nem precisamos dizer que API Keys

não devem ser gravadas desta forma.

Prefira outras formas de

armazenamento, de preferência

alguma forma que obtenha a chave

no momento da execução.

Relações de confiança

● Sempre utilize alguma forma de

autenticação. Relações baseadas em

confiança podem permitir que outros

jobs executem tarefas indesejadas.

E aí, vamos proteger nosso Jenkins?

www.concretesolutions.com.br

Rio de Janeiro – Rua São José, 90 – cj. 2121Centro – (21) 2240-2030

São Paulo – Av. Nações Unidas, 11.5413º andar - Brooklin - (11) 4119-0449

Ajudamos empresas a criar produtos digitais de sucesso