Como aplicar segurança na origem usando GitOps

Se o seu modelo de implantação do GitOps tiver problemas de segurança (por exemplo, uma permissão mal configurada devido a um erro de digitação), isso será propagado até que seja descoberto no tempo de execução , onde a maioria dos eventos de segurança são verificados ou encontrados.

E se você puder corrigir possíveis problemas de segurança em sua infraestrutura na fonte?

Vamos começar com o básico.

O que é Git?

Git é um sistema de controle de versão distribuído de código aberto . Ele rastreia as alterações feitas em arquivos (geralmente arquivos de texto, como código-fonte), permitindo e promovendo um modelo de trabalho colaborativo . É o_ de fato _padrão em sistemas de controle de versão hoje em dia.

Você pode ter seu próprio repositório git localmente em seu laptop, hospedá-lo em seu próprio servidor ou usar algum provedor como GitLab ou GitHub.

Existem diferentes “fluxos” sobre como gerenciar um repositório (git-flow, github-flow, etc.), mas um exemplo básico de como o git é usado é mais ou menos assim: Alterações nos arquivos são “confirmadas” pelos usuários por “bifurcando” o repositório e fazendo as devidas alterações em um “branch”.

Em seguida, o usuário cria uma solicitação (seja "solicitação pull", "solicitação de mesclagem" ou apenas "enviar um patch") para incluir essas alterações no repositório.

Depois disso, geralmente acontece uma discussão entre o “proprietário” e o usuário criador da requisição, e se tudo der certo a alteração é aceita e adicionada ao repositório.

NOTA: Se você quiser saber mais, aqui estão informações muito mais detalhadas sobre o mecanismo de solicitação git pull.

Para ver um exemplo do mundo real, basta navegar em seu repositório GitLab ou GitHub de código aberto favorito e navegar na guia Pull Request (ou Merge Request) (ou veja esta para uma divertida). Você pode ver as alterações propostas, comentários, rótulos, quem propôs as alterações, ferramentas executando validações contra as alterações propostas, notificações enviadas para as pessoas que estão assistindo ao repositório, etc.

O que é GitOps?

Simplificando, GitOps é apenas uma metodologia que usa um repositório git como a única fonte de verdade para seus ativos de software, para que você possa aproveitar o modelo de implantação git (solicitações pull, reversões, aprovações etc.) para seu software.

Existem livros ( The Path to GitOps , GitOps and Kubernetes ou GitOps Cloud-native Continuous Deployment ), white papers e mais postagens de blog do que conseguimos contar , mas vamos elaborar o propósito do GitOps dando uma olhada rápida em como as coisas evoluíram nos últimos anos.

Antes da nuvem, adicionar um novo servidor para hospedar seu aplicativo levava semanas. Você precisava pedir permissões, comprá-lo e realizar muitas tarefas manuais. Então, a virtualização tornou as coisas muito mais fáceis. Você solicita uma máquina virtual com algumas especificações e após alguns minutos, você tem acesso a ela.

Então, a nuvem. Solicitar servidores, rede, armazenamento e até mesmo bancos de dados, filas de mensagens, contêineres, material de aprendizado de máquina, sem servidor… é apenas uma chamada de API! Você solicita e alguns segundos depois, você consegue, assim mesmo. Você só precisa pagar pelo que usar. Isso também significa que a infraestrutura pode ser gerenciada como chamadas de API de execução de código... e onde você armazena seu código? Em um repositório git (ou qualquer outro sistema de versão de conteúdo).

O termo GitOps foi cunhado em 2017 pela Weaveworks , e parafraseando OpenGitOps , um sistema GitOps é baseado nos seguintes princípios:

• Declarativa : define “o quê”.
• Versionado e imutável : daí “git”.
• Puxado automaticamente : um agente observa o estado desejado e as alterações que ocorrem no código.
• Reconciliado continuamente : alguém mencionou o Kubernetes?

A essência da metodologia GitOps é basicamente um controlador Kubernetes ou controladores (ou agentes) em execução em seu cluster que observa os objetos Kubernetes em execução sobre ele (definido por um CustomResource ) comparando o estado atual com o estado especificado no repositório Git . Se não corresponder, ele corrige o aplicativo aplicando os manifestos encontrados no repositório.

NOTA: Existem abordagens ligeiramente diferentes para o GitOps, por exemplo, push vs. pull, como lidar com o gerenciamento de configuração, etc. Esses são tópicos avançados, mas, por enquanto, vamos nos ater ao básico.

O diagrama a seguir mostra um sistema GitOps simplificado:

• Uma alteração de código é enviada ao repositório Git pelo usuário.
• Em seguida, um processo é acionado no repositório para incorporar essas alterações no próprio aplicativo, incluindo a execução de ferramentas de automação nesse novo código para validá-lo.
• Depois que tudo estiver no lugar, o agente GitOps em execução no cluster Kubernetes, que está observando o repositório, realiza a reconciliação entre o estado desejado (o código no repositório) e o estado atual (os objetos em execução no próprio cluster Kubernetes).

Ser baseado no Git significa facilidade para os desenvolvedores. Eles não precisam se preocupar com uma nova ferramenta para interagir, mas sim aplicar as mesmas práticas usadas para gerenciar o código no repositório Git.

Falando em ferramentas GitOps, existem algumas já disponíveis, incluindo ferramentas de código aberto como Flux ou ArgoCD , ambos projetos de incubação do CNCF .

Para ter uma ideia de como é a definição de um aplicativo via GitOps, este é um exemplo de um aplicativo simples (armazenado em um repositório GitHub) gerenciado pelo Flux ou ArgoCD.

Com Fluxo:

 --- apiVersion: source.toolkit.fluxcd.io/v1beta2 kind: GitRepository metadata: name: my-example-app namespace: hello-world spec: interval: 30s ref: branch: master url: https://github.com/xxx/my-example-apps.git --- apiVersion: kustomize.toolkit.fluxcd.io/v1beta2 kind: Kustomization metadata: name: my-example-app namespace: hello-world spec: interval: 5m0s path: ./myapp prune: true sourceRef: kind: GitRepository name: my-example-app targetNamespace: hello-world

Com ArgoCD:

 apiVersion: argoproj.io/v1alpha1 kind: Application metadata: name: my-example-app namespace: hello-world spec: destination: namespace: my-example-app server: https://kubernetes.default.svc project: default source: path: myapp/ repoURL: https://github.com/xxx/my-example-apps.git targetRevision: HEAD syncPolicy: automated: {} syncOptions: - CreateNamespace=true

Ambos fazem referência ao repositório Git onde os manifestos do aplicativo são armazenados (Implantações), os NameSpaces e mais alguns detalhes.

GitOps x IaC

Infrastructure as Code é uma metodologia de tratamento dos blocos de construção de sua infraestrutura como código usando diferentes técnicas e ferramentas. Isso significa que, em vez de criar manualmente sua infraestrutura, como VMs, contêineres, redes ou armazenamento por meio da interface da web do seu provedor de infraestrutura favorito manualmente, você os define como código e, em seguida, eles são criados/atualizados/gerenciados pelas ferramentas que você escolher, como como terraform , crossplane , ou pulumi , entre outros.

Os benefícios são enormes. Você pode gerenciar sua infraestrutura como se fosse código (agora é código) e alavancar suas melhores práticas de desenvolvimento (automação, teste, rastreabilidade, controle de versão, etc.) para seus ativos de infraestrutura. Na verdade, há uma tendência de usar "Infraestrutura como Software" como um termo, porque é muito mais do que apenas código.

Há toneladas de informações sobre esse tópico, mas o recurso a seguir é um bom ponto de partida.

Como você provavelmente já percebeu, o GitOps utiliza a infraestrutura como código como modelo declarativo para definir a infraestrutura. Na verdade, IaC é um dos pilares do GitOps! Mas é muito mais porque o IaC não exige o restante dos princípios do GitOps.

GitOps x DevOps

Existem muitas definições do termo "DevOps". Depende de quem você pergunta, mas, para simplificar, "DevOps é a combinação de práticas e ferramentas para construir e entregar software reduzindo o atrito e em alta velocidade".

As metodologias DevOps podem alavancar o GitOps, pois o GitOps fornece uma estrutura que corresponde às práticas do DevOps, mas não é estritamente necessário.

E o NoOps?

O NoOps foi cunhado pela Forrester em 2021 e é uma abordagem radical para lidar com operações em que o ambiente de TI é abstraído e automatizado a ponto de não haver necessidade de gerenciá-lo manualmente.

O GitOps ajuda a reduzir as alterações manuais corrigindo aquelas com o estado desejado no repositório Git, mas aplicar um NoOps real a todo o ambiente de TI é uma meta aspiracional, e não uma meta real a partir de hoje .

O GitOps é apenas para Kubernetes?

Não. Kubernetes, o padrão do controlador e o modelo declarativo para definir objetos Kubernetes são uma combinação perfeita para uma metodologia GitOps, mas isso não significa que as metodologias GitOps não possam ser aplicadas sem o Kubernetes. Existem alguns desafios ao usar o GitOps fora do Kubernetes, como lidar com a idempotência, a exclusão/criação dos ativos, gerenciamento de segredos etc. Mas os princípios do GitOps podem ser aplicados sem o Kubernetes (e aplicando um pouco de criatividade).

GitOps e segurança

Vamos falar sobre os aspectos de segurança agora. A maioria das ferramentas de segurança detecta possíveis vulnerabilidades e problemas em tempo de execução (tarde demais). Para corrigi-los, é necessário executar um processo manual reativo (por exemplo, modificar diretamente um parâmetro em seu objeto k8s com o kubectl edit) ou, idealmente, a correção acontecerá na fonte e será propagada por toda a sua cadeia de suprimentos. Isso é o que é chamado de “ Shift Security Left ”. De corrigir o problema quando é tarde demais para corrigi-lo antes que aconteça.

Isso não significa que todos os problemas de segurança podem ser corrigidos na fonte, mas adicionar uma camada de segurança diretamente na fonte pode evitar alguns problemas.

Em primeiro lugar, aplicam-se as recomendações gerais de segurança.

• Reduzir a superfície de ataque
• Criptografe os segredos (usando segredos externos ou segredos selados)
• segmentação de rede
• RBAC
• Mantenha os softwares atualizados
• Aplicar privilégio mínimo
• Monitorar e medir
• …

Vejamos alguns cenários em que a metodologia GitOps pode melhorar sua segurança em geral:

• Evitar/Recusar alterações manuais (evitando Drift) . O repositório Git é a fonte da verdade. Se você tentar modificar a definição do aplicativo, a ferramenta GitOps reverterá essas alterações aplicando a versão armazenada no repositório Git.

• Alterações de reversão . Imagine que você introduziu um possível problema de segurança em um commit específico, modificando algum parâmetro na implementação de seu aplicativo. Aproveitando os recursos do Git, você pode reverter a alteração, se necessário, diretamente na origem, e a ferramenta GitOps reimplementará seu aplicativo sem interação do usuário.

• Resposta rápida. Se você achar que está usando uma imagem de contêiner vulnerável em seu aplicativo (por exemplo, MariaDB), basta criar um PR para atualizar a tag no arquivo de implantação e a ferramenta GitOps usará a nova tag em uma nova implantação.

• Rastreabilidade. Usando os recursos do Git, você pode verificar facilmente quando um arquivo foi alterado, as próprias alterações e o usuário que as promoveu. Você tem um log de auditoria de graça .

• Recuperação de desastres. Novamente, o repositório Git é a fonte da verdade. Se você precisar reimplantar seu aplicativo porque algo aconteceu, a definição está aí (é claro que você precisa ter um plano de recuperação de desastres para outras coisas, como os próprios dados).
• Controle de acesso. Você pode aplicar diferentes permissões a diferentes usuários em seus repositórios Git e até mesmo políticas como “só mesclar uma alteração após duas revisões positivas”.

Esses benefícios são bons o suficiente para justificar o uso de metodologias GitOps para melhorar sua postura de segurança e eles já vêm prontos, mas o GitOps é uma combinação de mais algumas coisas. Podemos fazer muito mais. GitHub, GitLab e outros provedores de repositórios Git permitem que você execute ações ou pipelines com base nas alterações realizadas em seu repositório Git, inclusive por solicitação pull, portanto, as possibilidades são infinitas. Alguns exemplos:

• Linting. A definição do aplicativo é code , e se a definição for verificada quanto à sintaxe incorreta, parâmetros ausentes e muito mais? Existem ferramentas (como o megainter ) que podem ser executadas contra as alterações que você fez para evitar surpresas mais tarde.

• Testando. Você pode até automatizar a criação de um cluster Kubernetes temporário para executar seu aplicativo com as alterações e executar alguns testes nele.

• Varredura de vulnerabilidades . Verificando as imagens de contêiner que você está usando em busca de vulnerabilidades antes de serem implantadas em seu ambiente.

• Política como código. Aproveitando o OPA , você pode até aplicar políticas aos seus manifestos para verificar possíveis problemas ou políticas personalizadas

Pensamentos finais

A metodologia GitOps traz algumas melhorias para o modelo de implantação e benefícios de segurança sem a necessidade de adicionar outra ferramenta .

Ele melhora a postura de segurança adicionando uma camada “shift left” diretamente ao código-fonte e, graças à flexibilidade do modelo pull-request, você pode adicionar facilmente verificações extras de segurança sem afetar ou modificar o tempo de execução.

Publicado também aqui .