Você já se perguntou como usar arquivos de configurações sensíveis em pipelines de CI/CD sem que isso crie uma vulnerabilidade no seu servidor ou no seu repositório GIT?
Afinal, como lidar com arquivos de configuração sensíveis em pipelines Jenkins?
META
Esse post é direcionado para quem tem a demanda de trabalhar com secrets e arquivos de configuração sensíveis com Jenkins Pipeline.
O que vemos aqui pode ser usado em pipelines de Continous Integragion, Continous Delivery, Continous Deployment, pipelines puramente de infraestrutura e qualquer caso em que precisamos de arquivos especiais e seguros para realizar parte de um pipeline jenkins.
Essa abordagem evita a criação de arquivos no repositório git, e também evita a necessidade de manter arquivos no servidor de build.
O exemplo que trouxe para dar vida ao post trata do update da versão da imagem, em um deployment do Kubernetes, usando um container que virtualiza o Kubectl e a secret contem o arquivo de configuração de acesso à API do Kubernetes.
A explicação desse conceito atende a qualquer cenário de uso do Jenkins Pipeline.
As possibilidades de uso são amplas e atende a qualquer caso em que seja necessário lidar com secrets e configurações sensíveis em arquivos.
Uma das formas de administrar um cluster kubernetes é com o Kubectl. Para usá-lo você precisa de um arquivo de configuração. Uma vez no local certo e com as keys certas, Kubectl pode ser usado para administrar seu cluster kubernetes. Isso é útil para implantar projetos novos ou para atualizar projetos.
Talvez a demanda seja simplesmente realizar um rollout de uma versão mais nova da aplicação.
Aqui está o dilema. O servidor de build precisaria ter um kubectl instalado, por isso no post Entrypoint vs CMD – v2 – Conteinerizando o Kubectl eu abordei como containerizei o kubectl. Você vai ver exemplo de uso dele, aqui no final desse post.
Eu tinha a opção de trabalhar com o plugin para Kubernetes, mas o plugin tem diversos objetivos e inclusive o de rodar o build no kubernetes. Não é meu caso. Meu interesse é simplesmente realizar um rollout, contento o update da versão da imagem docker em uma aplicação .NET que está implantada no kubernetes.
O que o Jenkins oferece para isso?
As secrets no jenkins são incríveis. Você tem uma interface para gerenciar essas secrets, que podem ser de diversos tipos:
- Secret Text
- Username and Password
- SSH Username with private key
- Certificate
- Secret File
Entre outros tipos customizados por plugins.
A mágica do Jenkins para isso é que você consegue expor a secret para seu script de pipeline de forma declarativa.
Durante a execução de um pipeline você usa o WithCredentials, criando um bloco que contém outros comandos seus. No escopo do bloco, ou seja entre o { e o } do bloco, o jenkins alimenta variáveis de ambiente antes de começar e às limpa após acabar o bloco, criando um escopo seguro, pela menor quantidade possível de tempo. Como mostra a imagem abaixo.
Cada tipo de credencial possui um tipo de binding diferente. O secret file, usa file como construtor da configuração.
Abaixo temos um exemplo do uso de credenciais, só que dessa vez o tipo é username and password. Note que o construtor do binding é diferente.
Esses detalhes de cada tipo de credencial são detalhados em For other credential types na documentação do Jenkins Pipeline.
O exemplo acima lida com a automação de testes e publicação de configurações no SonarQube.
Tutorial – Criando Credenciais no Jenkins
1 – Gerenciar Jenkins
Clique em Gerenciar Jenkins.
2 – Gerenciar Credenciais
Depois clique em Manage Credentials.
3 – Selecione o escopo
Selecione um escopo, no meu caso selecionei o escopo global.
4 – Adicionar credencial
Agora clique em Add Credentials.
5 – Escolhendo o tipo de credencial
Chegou a hora de escolher o tipo de credencial. Essa configuração fica em Kind. No meu caso eu queria um secret file.
Escolha Secret file
6 – O arquivo secreto
Faça upload do arquivo secreto.
7 – Adicionar credencial
Abaixo temos um exemplo do resultado.
Eu cheguei a criar com esse nome, depois que salvei eu vi que estava destoando das demais credenciais, portanto dropei e alterei o ID para K8S_CONFIG, respeitando o padrão não formal de nomes que uso.
Usando a secret
Agora é hora de usarmos nossa secret com o withCredentials.
Conclusão
O Jenkins é sem sombra de dúvidas uma solução incrível, é muito poderoso e esses detalhes fazem muita diferença. Endereçar esses detalhes torna todo o processo extremamente simples.
Boa Tarde
Pessoal estou usando o “secret text” do jenkins mas nao estou conseguindo passar a variavel alguem ja fez isso?
export ACCESS_TOKEN=$(curl -s https://antigo.com/accounts/api/v2/oauth2/token -X POST -H “Content-Type: application/json” -d “{\\”grant_type\\”: \\”client_credentials\\”, \\”client_id\\”: \\”$secret_file\\”, \\”client_secret\\”: \\”$secret_file\\”}” | sed -n ‘s|.*”access_token”:”\\([^”]*\\)”.*|\\1|p’)
Pessoal consegui colocar a variável de secret file descrevendo em enviroment
Boa!
Boa tarde !
O Jenkins consegue pegar um arquivo do pc e executar o código dentro desse arquivo ?
Se ele estiver instalado nesse pc, sim. Mas não é essa a proposta.
A ideia de qualquer servidor desses é estar distante dos PC’s, é estar na nuvem, em um servidor, distante do computador de um usuário.
A ideia é forçar um processo!
Então, só executa-se o que está versionado.
Só implanta o que está versionado.
E assim há a garantia de que o que foi implantado, passou pelo menos pelo git.