Como validar seu app em relação às políticas da empresa em um pipeline de integração contínua

Se sua organização usa o Anthos Config Management e o Policy Controller para gerenciar políticas em todos os clusters do Anthos, você pode validar a configuração de implantação de um aplicativo no pipeline de integração contínua (CI, na sigla em inglês). Neste tutorial, mostramos como alcançar esse resultado. É útil quando você é um desenvolvedor que está criando um pipeline de CI para um app, ou um engenheiro de plataforma que está criando um modelo de pipeline de CI para várias equipes de app.

As políticas são uma parte importante da segurança e da conformidade de uma organização. O Policy Controller, que faz parte do Anthos Config Management, permite que sua organização gerencie essas políticas de maneira centralizada e declarativa para todos os clusters. Como desenvolvedor, você pode aproveitar a natureza centralizada e declarativa dessas políticas. Você pode usar essas características para validar seu aplicativo em relação a essas políticas o mais cedo possível em seu fluxo de trabalho de desenvolvimento. Aprender sobre violações de políticas no pipeline de CI em vez de fazê-lo durante a implantação tem duas vantagens principais: permite que você mude para a esquerda na segurança e diminua o feedback loop, reduzindo o tempo e o custo necessários para corrigir essas violações.

Se você for cobrado pelo Anthos Config Management e pelo Policy Controller e quiser criar um pipeline de CI para eles (e não para um app específico), consulte Como usar o Policy Controller em um pipeline de CI.

Neste tutorial, o Cloud Build é usado como uma ferramenta de CI e um repositório do GitHub de amostra com políticas de demonstração.

Recursos

Este tutorial usa várias ferramentas do ecossistema do Kubernetes. Esta seção explica o que são essas ferramentas, como elas interagem umas com as outras e se você pode substituí-las por outra coisa. As ferramentas que usará neste tutorial são:

  • Policy Controller: é um produto do Google Cloud que faz parte do Anthos Config Management. Ele é baseado no projeto de código aberto Open Policy Agent, Gatekeeper. O Policy Controller aplica políticas sobre os objetos criados em um cluster do Kubernetes (por exemplo, impedindo o uso de uma opção específica ou aplicação do uso de um rótulo específico). Essas políticas são chamadas de restrições. As restrições são definidas como Recursos personalizados do Kubernetes (em inglês). O Config Sync (disponível como um produto independente ou como parte do Anthos Config Management) permite declarar essas restrições em um repositório Git e aplicar fluxos de trabalho de desenvolvimento tradicionais ao processo de gerenciamento de políticas. É possível usar o Open Policy Agent - Gatekeeper, em vez do Policy Controller para sua implementação.

  • GitHub: neste tutorial, usamos o GitHub para hospedar repositórios Git: um para um aplicativo de amostra e outro para o Anthos Config Management (que contém as restrições do Policy Controller). Para simplificar, os dois repositórios são duas pastas diferentes em um único repositório Git. Na realidade, seriam repositórios diferentes. Use qualquer solução Git.

  • Cloud Build: o Cloud Build é a solução de CI do Google Cloud. Neste tutorial, nós o usaremos para executar os testes de validação. Os detalhes da implementação podem variar de um sistema de CI para outro, mas os conceitos descritos neste tutorial podem ser usados com qualquer sistema de CI baseado em contêiner.

  • Kustomize: o Kustomize é uma ferramenta de personalização nas configurações do Kubernetes. Isso é feito por meio de configurações de "base" e da aplicação de personalizações. Com ele, você tem uma abordagem de DRY (Não se repita) para configurações do Kubernetes. Com o Kustomize, você mantém elementos comuns a todos os seus ambientes nas configurações básicas e cria personalizações por ambiente. Neste tutorial, manteremos as configurações do Kustomize no repositório de aplicativos à medida que "criamos" as configurações no pipeline de CI. Por exemplo, aplicando personalizações. Use os conceitos descritos neste tutorial com qualquer ferramenta que produz configurações do Kubernetes e que estão prontas para serem aplicadas a um cluster. Por exemplo, o comando do modelo do Helm.

  • Kpt: o Kpt é uma ferramenta para criar fluxos de trabalho para configurações do Kubernetes. O Kpt permite buscar, exibir, personalizar, atualizar, validar e aplicar configurações do Kubernetes. Como ela funciona com arquivos Git e YAML, é compatível com a maioria das ferramentas atuais do ecossistema do Kubernetes. Neste tutorial, usamos o kpt no pipeline de CI para buscar as restrições do repositório do Anthos Config Management e validar as configurações do Kubernetes com base nessas restrições.

Canal

O pipeline de CI que estamos us uando neste tutorial é mostrado no diagrama abaixo. Ele é executado no Cloud Build, e os comandos são executados em um diretório contendo uma cópia do repositório do app de amostra. O pipeline começa gerando as configurações finais do Kubernetes com o kustomize. Depois, busca as restrições que queremos validar no repositório do Anthos Config Management usando o kpt. Por fim, o kpt é usado para validar as configurações do Kubernetes de acordo com essas restrições. Para realizar essa última etapa, usamos uma função de configuração específica chamada gatekeeper-validate que realiza essa validação. Neste tutorial, você acionará o pipeline de CI manualmente. No entanto, na realidade, ele seria configurado para ser executado após um git push para seu repositório Git.

Pipeline de CI para o  Policy Controller

Objetivos

  • Executar um pipeline de CI para um aplicativo de amostra com o Cloud Build.
  • Observar que o pipeline falhou devido a uma violação da política.
  • Modificar o repositório do app de amostra para obedecer às políticas.
  • Executar o pipeline de CI novamente com êxito.

Custos

Neste tutorial, usamos o seguinte componente faturável do Google Cloud:

  • Cloud Build

Para gerar uma estimativa de custo baseada na projeção de uso deste tutorial, use a calculadora de preços.

Ao concluir este tutorial, exclua os recursos criados para evitar o faturamento contínuo. Veja mais detalhes em Limpar.

Antes de começar

  1. Selecione ou crie um projeto do Cloud.

    ACESSE A PÁGINA "GERENCIAR RECURSOS"

  2. Ative o faturamento do projeto.

    ATIVAR FATURAMENTO

  3. Abra o Cloud Shell para executar os comandos listados neste tutorial.

    ACESSAR O CLOUD SHELL

  4. Se o comando gcloud config get-value project não retornar o ID do projeto que foi selecionado, configure o Cloud Shell para usar seu projeto.

    gcloud config set project PROJECT_ID
    
  5. No Cloud Shell, ative a API Cloud Build necessária.

    gcloud services enable cloudbuild.googleapis.com
    

Validar as configurações de aplicativos de amostra

Nesta seção, você executará um pipeline de CI com o Cloud Build para um repositório de aplicativo de amostra que fornecemos. Este pipeline valida a configuração do Kubernetes disponível nesse repositório de aplicativos de amostra em relação às restrições disponíveis em um repositório de amostra do Anthos Config Management.

  1. No Cloud Shell, clone o repositório do app de amostra.

    git clone https://github.com/GoogleCloudPlatform/csp-config-management.git
    
  2. Execute o pipeline de CI com o Cloud Build Os registros do build são exibidos diretamente no Cloud Shell.

    cd csp-config-management/ci-app/app-repo
    gcloud builds submit .
    

    O pipeline executado é definido no arquivo a seguir.

    steps:
    - id: 'Prepare config'
      # This step builds the final manifests for the app
      # using kustomize and the configuration files
      # available in the repository.
      name: 'gcr.io/google.com/cloudsdktool/cloud-sdk'
      entrypoint: '/bin/sh'
      args: ['-c', 'mkdir hydrated-manifests && kubectl kustomize config/prod > hydrated-manifests/prod.yaml']
    - id: 'Download policies'
      # This step fetches the policies from the Anthos Config Management repository
      # and consolidates every resource in a single file.
      name: 'gcr.io/kpt-dev/kpt'
      entrypoint: '/bin/sh'
      args: ['-c', 'kpt pkg get https://github.com/GoogleCloudPlatform/csp-config-management.git/ci-app/acm-repo/cluster@1.0.0 constraints
                      && kpt fn source constraints/ hydrated-manifests/ > hydrated-manifests/kpt-manifests.yaml']
    - id: 'Validate against policies'
      # This step validates that all resources comply with all policies.
      name: 'gcr.io/config-management-release/policy-controller-validate'
      args: ['--input', 'hydrated-manifests/kpt-manifests.yaml']
  3. Após alguns minutos, observe que o pipeline falha com o seguinte erro:

    [...]
    Step #2 - "Validate against policies": gcr.io/config-management-release/policy-controller-validate:latest
    Step #2 - "Validate against policies": Error: Found 1 violations:
    Step #2 - "Validate against policies":
    Step #2 - "Validate against policies": [1] Deployment objects should have an 'owner' label indicating who created them.
    Step #2 - "Validate against policies":
    Step #2 - "Validate against policies": name: "nginx-deployment"
    Step #2 - "Validate against policies": path: prod.yaml
    [...]
    

    A restrição que a configuração viola é definida no arquivo a seguir. É um recurso personalizado do Kubernetes chamado K8sRequiredLabels.

    apiVersion: constraints.gatekeeper.sh/v1beta1
    kind: K8sRequiredLabels
    metadata:
      name: deployment-must-have-owner
    spec:
      match:
        kinds:
          - apiGroups: ["apps"]
            kinds: ["Deployment"]
      parameters:
        labels:
          - key: "owner"
        message: "Deployment objects should have an 'owner' label indicating who created them."

    Para o modelo de restrição correspondente a essa restrição, consulte este arquivo (em inglês) no GitHub.

  4. Crie a configuração completa do Kubernetes e observe que o rótulo owner está realmente ausente. Para criar a configuração:

    kubectl kustomize config/prod
    

Corrija o app para estar em conformidade com as políticas da empresa

Nesta seção, você corrige a violação da política usando o Kustomize.

  1. No Cloud Shell, adicione uma seção commonLabels ao arquivo base do Kustomize:

    cat <<EOF >> config/base/kustomization.yaml
    commonLabels:
      owner: myself
    EOF
    
  2. Crie a configuração completa do Kubernetes e observe que o rótulo owner está presente:

    kubectl kustomize config/prod
    
  3. Execute novamente o pipeline de CI com o Cloud Build:

    gcloud builds submit .
    

    O pipeline agora é bem-sucedido com a seguinte saída:

    [...]
    Finished Step #2 - "Validate against policies"
    PUSH
    DONE
    [...]
    

Limpar

  1. No Console do Cloud, acesse a página Gerenciar recursos:

    Acessar a página "Gerenciar recursos"

  2. Na lista de projetos, selecione o projeto que você quer excluir e clique em Excluir .
  3. Na caixa de diálogo, digite o ID do projeto e clique em Encerrar para excluí-lo.

A seguir