Como melhorar a segurança dos seus pipelines de CI/CD com GitHub Runners

Cenário:

Você é um desenvolvedor que usa GitHub Actions para automatizar o processo de desenvolvimento e entrega de software. Você está satisfeito com a flexibilidade e a escalabilidade dos GitHub Actions, mas está procurando maneiras de melhorar a segurança dos seus pipelines.

Problema:

Os pipelines de CI/CD podem conter informações confidenciais, como credenciais de acesso a bancos de dados, API e serviços em nuvem. Ao armazenar essas credenciais nas secrets do GitHub, você corre o risco de elas serem comprometidas se o seu repositório for invadido.

Solução:

A combinação de GitHub Runners com Kubernetes é uma solução poderosa para melhorar a segurança dos seus pipelines de CI/CD.

Como funciona?

Os GitHub Runners são agentes que executam seus jobs de CI/CD. Você pode hospedá-los localmente ou na nuvem.

O Kubernetes é uma plataforma de orquestração de containers que pode ser usada para gerenciar os GitHub Runners. Com o Kubernetes, você pode executar os seus jobs em containers isolados, o que ajuda a proteger as suas credenciais confidenciais.

Vantagens:

Aqui estão algumas das vantagens de usar GitHub Runners com Kubernetes para melhorar a segurança dos seus pipelines de CI/CD:

Isolamento: Os jobs são executados em containers isolados, o que ajuda a proteger as suas credenciais confidenciais de acesso não autorizado.
Controle de acesso: Você pode controlar quem tem acesso aos seus runners, o que ajuda a proteger as suas credenciais confidenciais de vazamentos.
Auditoria: Você pode auditar o acesso aos seus runners, o que ajuda a detectar qualquer atividade maliciosa.

Exemplos:

Aqui estão alguns exemplos de como a combinação de GitHub Runners com Kubernetes pode ser usada para melhorar a segurança dos seus pipelines de CI/CD:

**Você pode usar credenciais de serviços da AWS para interagir com serviços da AWS em seus pipelines. Isso ajuda a proteger as suas credenciais da AWS de serem comprometidas se o seu repositório for invadido.
**Você pode usar uma ferramenta de gerenciamento de secrets para armazenar as suas credenciais confidenciais em um local seguro. Isso ajuda a proteger as suas credenciais de serem comprometidas, mesmo se o seu repositório for invadido.

Se você está procurando maneiras de melhorar a segurança dos seus pipelines de CI/CD, considere usar a combinação de GitHub Runners com Kubernetes. Essa solução pode ajudá-lo a proteger as suas credenciais confidenciais e evitar invasões.

Vamos entender na prática

Os jobs do GitHub Actions são executados na nuvem por padrão; no entanto, às vezes queremos executar trabalhos em nosso próprio ambiente personalizado/privado, onde temos controle total. É aí que um executor auto-hospedado nos salva desse problema.

Para obter uma compreensão básica da execução de executores auto-hospedados no cluster Kubernetes, este artigo é perfeito para você.

Estaremos nos concentrando na execução de GitHub Actions em um executor auto-hospedado no Kubernetes.

Um exemplo de caso de uso seria criar uma automação no GitHub Actions para executar consultas MySQL no banco de dados MySQL em execução em uma rede privada (ou seja, banco de dados MySQL, que não é acessível publicamente). Um executor auto-hospedado requer o provisionamento e a configuração de uma instância de máquina virtual; aqui, estamos executando no Kubernetes. Para executar um executor auto-hospedado em um cluster Kubernetes, o action-runner-controller nos ajuda a tornar isso possível.

Este artigo tem como objetivo testar executores auto-hospedados no Kubernetes e abrange:

Implantando banco de dados MySQL no minikube, que é acessível apenas no cluster Kubernetes.
Implantando executores de ação auto-hospedados no minikube.
Executando GitHub Action no minikube para executar consultas MySQL no banco de dados MySQL.

Etapas para concluir este tutorial:

Crie um repositório GitHub

Crie um repositório privado no GitHub. Por exemplo com o nome “repo-teste/action-runner-poc” .

Configure um cluster Kubernetes usando minikube

Instale o Docker.
Instale o Minikube.
Instalar Helm
Instalar kubectl

Instale o cert-manager em um cluster Kubernetes

Por padrão, o actions-runner-controller usa o cert-manager para gerenciamento de certificados do webhook de admissão , portanto, precisamos ter certeza de que o cert-manager está instalado no Kubernetes antes de instalarmos o actions-runner-controller.

Execute os comandos do leme abaixo para instalar o cert-manager no minikube.

Verifique a instalação usando “kubectl –namespace cert-manager get all”. Se tudo estiver bem, você verá uma saída conforme abaixo:

Configurando autenticação para executores hospedados

Existem duas maneiras de o actions-runner-controller se autenticar com a API do GitHub (no entanto, apenas 1 pode ser configurado por vez):

Usando um aplicativo GitHub (não compatível com executores de nível empresarial devido à falta de suporte do GitHub).
Usando um PAT (token de acesso pessoal)

Para manter este artigo simples, vamos usar o PAT.

Para autenticar um action-runner-controller com a API GitHub, podemos usar um PAT com o action-runner-controller registrando um executor auto-hospedado.

Vá para conta > Configurações > Configurações de desenvolvedores > Token de acesso pessoal. Clique em “Gerar novo token”. Nos escopos, selecione “Controle total de repositórios privados”.

Clique no botão “Gerar token”.

Copie o token gerado e execute os comandos abaixo para criar um segredo do Kubernetes, que será usado pela implantação do action-runner-controller.

export GITHUB_TOKEN=XXXxxxXXXxxxxXYAVNa kubectl create ns actions-runner-system

Criar segredokubectl create secret generic controller-manager -n actions-runner-system –from-literal=github_token=${GITHUB_TOKEN}

Instale o controlador do executor de ação no cluster Kubernetes

Execute os comandos do leme abaixo

helm repo add actions-runner-controller https://actions-runner-controller.github.io/actions-runner-controller helm repo update helm upgrade –install –namespace actions-runner-system –create-namespace –wait actions-runner-controller actions-runner-controller/actions-runner-controller –set syncPeriod=1m

Verifique se o action-runner-controller foi instalado corretamente usando o comando abaixo

kubectl –namespace actions-runner-system get all

Crie um executor de repositório

Crie um objeto RunnerDeployment Kubernetes, que criará um executor auto-hospedado chamado k8s-action-runner para o repositório GitHub repo-teste/< /span>action-runner-poc
Atualize o nome do repositório de “repo-teste/action-runner-poc< a i=4>” para “<Seu-repo-name>”
Para criar o objeto RunnerDeployment, crie o arquivo runner.yaml da seguinte maneira:

apiVersion: actions.summerwind.dev/v1alpha1 kind: RunnerDeployment metadata: name: k8s-action-runner namespace: actions-runner-system spec: replicas: 2 template: spec: repository: reu-repo/action-runner-poc

Para criar, execute este comando:

kubectl create -f runner.yaml

Verifique se o pod está em execução usando o comando abaixo:kubectl get pod -n actions-runner-system | grep -i “k8s-action-runner”

Se tudo correr bem, você deverá ver dois action runners no Kubernetes, e os mesmos estão registrados no Github. Verifique em Configurações > Ações > Runner do seu repositório.

Verifique o pod com kubectl get po -n actions-runner-system

Com estes etapas você já será capaz de usar os seus Runners dentro do k8s.

Agora completando o teste…

Instale um banco de dados MySQL no cluster Kubernetes

Crie PV e PVC para banco de dados MySQL.
Crie mysql-pv.yaml com o conteúdo abaixo.

apiVersion: v1 kind: PersistentVolume metadata: name: mysql-pv-volume labels: type: local spec: capacity: storage: 2Gi accessModes: – ReadWriteOnce hostPath: path: “/mnt/data” — apiVersion: v1 kind: PersistentVolumeClaim metadata: name: mysql-pv-claim spec: accessModes: – ReadWriteOnce resources: requests: storage: 2Gi

Criar namespace mysql

kubectl create ns mysql

Agora aplique mysql-pv.yaml para criar PV e PVC

kubectl create -f mysql-pv.yaml -n mysql

Crie o arquivo mysql-svc-deploy.yaml e adicione o conteúdo abaixo a mysql-svc-deploy.yaml

Aqui, usamos MYSQL_ROOT_PASSWORD como “senha”.apiVersion: v1 kind: Service metadata: name: mysql spec: ports: – port: 3306 selector: app: mysql clusterIP: None — apiVersion: apps/v1 kind: Deployment metadata: name: mysql spec: selector: matchLabels: app: mysql strategy: type: Recreate template: metadata: labels: app: mysql spec: containers: – image: mysql:5.6 name: mysql env: # Use secret in real usage – name: MYSQL_ROOT_PASSWORD value: password ports: – containerPort: 3306 name: mysql volumeMounts: – name: mysql-persistent-storage mountPath: /var/lib/mysql volumes: – name: mysql-persistent-storage persistentVolumeClaim: claimName: mysql-pv-claim

Crie o serviço e a implantação

kubectl create -f mysql-svc-deploy.yaml -n mysql

Verifique se o banco de dados MySQL está em execução

kubectl get po -n mysql

Crie um segredo de repositório GitHub para armazenar a senha do MySQL

Como usaremos a senha do MySQL no arquivo de fluxo de trabalho de ação do GitHub como uma boa prática, não devemos usá-la em texto simples. Portanto, armazenaremos a senha do MySQL nos segredos do GitHub e usaremos esse segredo em nosso arquivo de fluxo de trabalho de ação do GitHub.

Crie um segredo no repositório GitHub e dê o nome ao segredo como “MYSQL_PASS”, e nos valores digite “senha”.

Crie um arquivo de fluxo de trabalho GitHub

A sintaxe YAML é usada para escrever fluxos de trabalho GitHub. Para cada fluxo de trabalho, usamos um arquivo YAML separado, que armazenamos no diretório .github/workflows/. Portanto, crie um diretório .github/workflows/ em seu repositório e crie um arquivo .github/workflows/mysql_workflow.yaml da seguinte maneira.

— name: Example 1 on: push: branches: [ main ] jobs: build: name: Build-job runs-on: self-hosted steps: – name: Checkout uses: actions/checkout@v2 – name: MySQLQuery env: PASS: ${{ secrets.MYSQL_PASS }} run: | docker run -v ${GITHUB_WORKSPACE}:/var/lib/docker –rm mysql:5.6 sh -c “mysql -u root -p$PASS -hmysql.mysql.svc.cluster.local </var/lib/docker/test.sql”

Se você verificar o comando docker run no arquivo mysql_workflow.yaml, estamos nos referindo ao arquivo .sql, ou seja, test.sql. Portanto, crie um arquivo test.sql em seu repositório da seguinte forma:

use mysql; CREATE TABLE IF NOT EXISTS Persons ( PersonID int, LastName varchar(255), FirstName varchar(255), Address varchar(255), City varchar(255) ); SHOW TABLES;

Em test.sql, estamos executando consultas MySQL como criar tabelas.
Envie as alterações para o branch principal do seu repositório.
Se tudo estiver bem, você poderá ver que a ação do GitHub está sendo executada em um executor auto-hospedado. Você pode verificar isso na guia “Ações” do seu repositório.

Você pode verificar os logs do fluxo de trabalho para ver a saída de SHOW TABLES — um comando que usamos no arquivo test.sql — e verificar se as tabelas de pessoas foram criadas.

Referências:

Leitura indicada:

Gostou do artigo? Não se esqueça de curtir e compartilhar o artigo para ajudar mais pessoas com dúvidas em tecnologia.

Tecnologia