Se o seu (por exemplo, uma permissão mal configurada devido a um erro de digitação), , onde a maioria dos eventos de segurança são verificados ou encontrados. modelo de implantação do GitOps tiver problemas de segurança isso será propagado até que seja descoberto no tempo de execução 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? . Ele rastreia as alterações feitas em arquivos (geralmente arquivos de texto, como código-fonte), . É o_ de fato _padrão em sistemas de controle de versão hoje em dia. é um sistema de controle de versão distribuído de código aberto Git permitindo e promovendo um modelo de trabalho colaborativo 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, estão informações muito mais detalhadas sobre o mecanismo de solicitação git pull. aqui 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 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. esta O que é GitOps? Simplificando, para que você possa aproveitar o modelo de implantação git (solicitações pull, reversões, aprovações etc.) para seu software. GitOps é apenas uma metodologia que usa um repositório git como a única fonte de verdade para seus ativos de software, Existem livros ( , ou ), e , mas vamos elaborar o propósito do dando uma olhada rápida em como as coisas evoluíram nos últimos anos. The Path to GitOps GitOps and Kubernetes GitOps Cloud-native Continuous Deployment white papers mais postagens de blog do que conseguimos contar GitOps 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 , e parafraseando , um sistema GitOps é baseado nos seguintes princípios: 2017 pela Weaveworks OpenGitOps : define “o quê”. Declarativa : daí “git”. Versionado e imutável : um agente observa o estado desejado e as alterações que ocorrem no código. Puxado automaticamente : alguém mencionou o Kubernetes? Reconciliado continuamente A (ou agentes) em execução em seu cluster que observa os objetos Kubernetes em execução sobre ele (definido por um ) . Se não corresponder, ele o aplicativo aplicando os manifestos encontrados no repositório. essência da metodologia GitOps é basicamente um controlador Kubernetes ou controladores CustomResource comparando o estado atual com o estado especificado no repositório Git corrige 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 ou , ambos . Flux ArgoCD 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 é 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 , , ou , entre outros. Infrastructure as Code terraform crossplane pulumi 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 é um bom ponto de partida. recurso a seguir 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 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. 2021 O ajuda a reduzir as alterações manuais corrigindo aquelas com o estado desejado no repositório Git, mas . GitOps 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 e o 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 (e aplicando um pouco de criatividade). padrão do controlador modelo declarativo os princípios do GitOps podem ser aplicados sem o Kubernetes 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 “ ”. De corrigir o problema quando é tarde demais para corrigi-lo antes que aconteça. Shift Security Left 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: . 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. Evitar/Recusar alterações manuais (evitando Drift) . 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. Alterações de reversão 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. Resposta rápida. 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 . Rastreabilidade. de graça 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). Recuperação de desastres. 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”. Controle de acesso. 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 ou com base nas alterações realizadas em seu repositório Git, inclusive por solicitação pull, portanto, as possibilidades são infinitas. Alguns exemplos: ações pipelines A definição do aplicativo , e se a definição for verificada quanto à sintaxe incorreta, parâmetros ausentes e muito mais? Existem ferramentas (como o ) que podem ser executadas contra as alterações que você fez para evitar surpresas mais tarde. Linting. é code megainter Você pode até automatizar a para executar seu aplicativo com as alterações e executar alguns testes nele. Testando. criação de um cluster Kubernetes temporário . Verificando as que você está usando em busca de vulnerabilidades antes de serem implantadas em seu ambiente. Varredura de vulnerabilidades imagens de contêiner Aproveitando o , você pode até aplicar políticas aos seus manifestos para verificar possíveis problemas ou políticas personalizadas Política como código. OPA Pensamentos finais A e . metodologia GitOps traz algumas melhorias para o modelo de implantação benefícios de segurança sem a necessidade de adicionar outra ferramenta 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. Ele melhora a postura de segurança adicionando uma camada “shift left” diretamente ao código-fonte Publicado também . aqui
