Valide apps em relação às políticas da empresa numa pipeline de CI

Se a sua organização usar o Policy Controller para gerir políticas nos respetivos clusters do Google Kubernetes Engine, pode validar a configuração de implementação de uma app no respetivo pipeline de integração contínua (IC). Este tutorial demonstra como alcançar este resultado. A validação da sua app é útil se for um programador a criar um pipeline de CI para uma app ou um engenheiro de plataforma a criar um modelo de pipeline de CI para várias equipas de apps.

Esta página destina-se a administradores de TI e operadores que querem garantir que todos os recursos executados na plataforma de nuvem cumprem os requisitos de conformidade organizacionais, fornecendo e mantendo a automatização para auditar ou aplicar, e que gerem o ciclo de vida da infraestrutura tecnológica subjacente. Para saber mais sobre as funções comuns e as tarefas de exemplo que referimos no Google Cloud conteúdo, consulte Funções e tarefas comuns do utilizador do GKE.

As políticas são uma parte importante da segurança e da conformidade de uma organização. O Policy Controller permite que a sua organização faça a gestão dessas políticas de forma centralizada e declarativa para todos os seus clusters. Enquanto programador, pode tirar partido da natureza centralizada e declarativa dessas políticas. Pode usar essas caraterísticas para validar a sua app em relação a essas políticas o mais cedo possível no seu fluxo de trabalho de desenvolvimento. A aprendizagem sobre violações de políticas no pipeline de CI, em vez de durante a implementação, tem duas vantagens principais: permite deslocar a segurança para a esquerda e reforça o ciclo de feedback, reduzindo o tempo e o custo necessários para corrigir essas violações.

Este tutorial usa o Cloud Build como uma ferramenta de CI e um repositório de exemplo do GitHub que contém políticas para demonstrações.

Recursos

Este tutorial usa várias ferramentas do Kubernetes. Esta secção explica o que são essas ferramentas, como interagem entre si e se pode substituí-las por outra coisa.

As ferramentas que usa neste tutorial incluem o seguinte:

• Policy Controller: baseia-se no projeto de código aberto Open Policy Agent – Gatekeeper. O Policy Controller aplica políticas sobre os objetos criados num cluster do Kubernetes (por exemplo, impedindo a utilização de uma opção específica ou aplicando a utilização de uma etiqueta específica). Essas políticas são denominadas restrições. As restrições são definidas como recursos personalizados do Kubernetes. O Policy Controller está disponível como parte do GKE, mas pode usar o Open Policy Agent - Gatekeeper em vez do Policy Controller para a sua implementação.

• GitHub: Neste tutorial, usamos o GitHub para alojar os repositórios Git: um para uma app de exemplo e outro que contém as restrições para o Policy Controller. Para simplificar, os dois repositórios são duas pastas diferentes num único repositório Git. Na realidade, seriam repositórios diferentes. Pode usar qualquer solução Git.

• Cloud Build: O Cloud Build é a solução de CI Google Cloud. Neste tutorial, vamos usá-lo para executar os testes de validação. Embora os detalhes da implementação possam variar de um sistema de IC para outro, os conceitos descritos neste tutorial podem ser usados com qualquer sistema de IC baseado em contentores.

• Kustomize: O Kustomize é uma ferramenta de personalização para configurações do Kubernetes. Funciona através da aplicação de personalizações a configurações "base". Permite-lhe ter uma abordagem DRY (Don't Repeat Yourself) às configurações do Kubernetes. Com o Kustomize, mantém os elementos comuns a todos os seus ambientes nas configurações base e cria personalizações por ambiente. Neste tutorial, mantemos as configurações do Kustomize no repositório da app e "criamos" (por exemplo, aplicamos as personalizações) as configurações no pipeline de CI. Pode usar os conceitos descritos neste tutorial com qualquer ferramenta que produza configurações do Kubernetes prontas para serem aplicadas a um cluster (por exemplo, o comando helm template).

• Kpt: O Kpt é uma ferramenta para criar fluxos de trabalho para configurações do Kubernetes. O Kpt permite-lhe obter, apresentar, personalizar, atualizar, validar e aplicar configurações do Kubernetes. Como funciona com ficheiros Git e YAML, é compatível com a maioria das ferramentas existentes do ecossistema Kubernetes. Neste tutorial, usamos o kpt no pipeline de CI para obter as restrições do repositório anthos-config-management-samples e para validar as configurações do Kubernetes em relação a essas restrições.

Fornecimento

O pipeline de CI que usamos neste tutorial é apresentado no diagrama seguinte:

O pipeline é executado no Cloud Build e os comandos são executados num diretório que contém uma cópia do repositório da app de exemplo. O pipeline começa gerando as configurações finais do Kubernetes com o Kustomize. Em seguida, obtém as restrições que queremos validar a partir do repositório anthos-config-management-samples através do kpt. Por último, usa o kpt para validar as configurações do Kubernetes em relação a essas restrições. Para realizar este último passo, usamos uma função de configuração específica denominada gatekeeper que realiza esta validação. Neste tutorial, aciona o pipeline de CI manualmente, mas, na realidade, configurá-lo-ia para ser executado após uma git push para o seu repositório Git.

Objetivos

• Execute um pipeline de CI para uma app de exemplo com o Cloud Build.
• Observe que o pipeline falha devido a uma violação de política.
• Modifique o repositório da app de exemplo para estar em conformidade com as políticas.
• Executar novamente o pipeline de CI com êxito.

Custos

Este tutorial usa os seguintes componentes faturáveis do Google Cloud:

• Cloud Build
• Google Kubernetes Engine

Para gerar uma estimativa de custos com base na sua utilização projetada, use a calculadora de preços.

Quando terminar este tutorial, pode evitar a faturação contínua eliminando os recursos que criou. Para mais detalhes, consulte a secção Limpar.

Antes de começar

1. Selecione ou crie um Google Cloud projeto. Na Google Cloud consola, aceda à página Gerir recursos:

   Aceda a Gerir recursos

2. Ative a faturação para o seu projeto.

3. Para executar os comandos indicados neste tutorial, abra o Cloud Shell:

   Aceda ao Cloud Shell

4. No Cloud Shell, execute gcloud config get-value project.

   Se o comando não devolver o ID do projeto que acabou de selecionar, configure o Cloud Shell para usar o seu projeto:

   gcloud config set project PROJECT_ID
   

   Substitua PROJECT_ID pelo ID do seu projeto.

5. No Cloud Shell, ative a API Cloud Build necessária:

   gcloud services enable cloudbuild.googleapis.com
   

Valide as configurações da app de amostra

Nesta secção, executa um pipeline de CI com o Cloud Build para um repositório de apps de exemplo que fornecemos. Este pipeline valida a configuração do Kubernetes disponível nesse repositório de apps de exemplo em relação às restrições disponíveis num repositório anthos-config-management-samples.

Para validar as configurações da app:

1. No Cloud Shell, clone o repositório da app de exemplo:

   git clone https://github.com/GoogleCloudPlatform/anthos-config-management-samples.git
   

2. Execute o pipeline de CI com o Cloud Build. Os registos da compilação são apresentados diretamente no Cloud Shell.

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

   O pipeline que executa está definido no seguinte ficheiro.

   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/anthos-config-management-samples.git/ci-app/acm-repo/cluster@main 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/kpt-fn/gatekeeper:v0.2'
     args: ['--input', 'hydrated-manifests/kpt-manifests.yaml']

   No Policy Controller, as restrições são instanciações de modelos de restrições. Os modelos de restrições contêm o código Rego real usado para implementar a restrição. A função gcr.io/kpt-fn/gatekeeper precisa do modelo de restrição e das definições de restrição para funcionar. O repositório de políticas de exemplo contém ambos, mas, na realidade, podem ser armazenados em locais diferentes. Use o comando kpt pkg get conforme necessário para transferir os modelos de restrições e as restrições.

   Este tutorial usa o gcr.io/kpt-fn/gatekeeper com o Cloud Build para validar recursos, mas existem duas outras alternativas que pode usar:

   • Use a gcr.io/kpt-fn/gatekeeper função com kpt:

   kpt fn eval hydrated-manifests/kpt-manifests.yaml --image gcr.io/kpt-fn/gatekeeper:v0.2
   

   • Use a ferramenta de linha de comandos gator:

   gator test -f hydrated-manifests/kpt-manifests.yaml
   

3. Após alguns minutos, observe que o pipeline falha com o seguinte erro:

   [...]
   Step #2 - "Validate against policies": [error] apps/v1/Deployment/nginx-deployment : Deployment objects should have an 'owner' label indicating who created them.
   Step #2 - "Validate against policies": violatedConstraint: deployment-must-have-owner
   Finished Step #2 - "Validate against policies"
   2022/05/11 18:55:18 Step Step #2 - "Validate against policies" finished
   2022/05/11 18:55:19 status changed to "ERROR"
   ERROR
   ERROR: build step 2 "gcr.io/kpt-fn/gatekeeper:v0.2" failed: exit status 1
   2022/05/11 18:55:20 Build finished with ERROR status
   

   A restrição que a configuração está a violar está definida no seguinte ficheiro. É um recurso personalizado do Kubernetes denominado 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 esta restrição, consulte requiredlabels.yaml no GitHub.

4. Crie a configuração completa do Kubernetes e observe que a etiqueta owner está em falta. Para criar a configuração:

   kubectl kustomize config/prod
   

Corrija a app para agir em conformidade com as políticas da empresa

Nesta secção, corrige a violação de política através do Kustomize:

1. No Cloud Shell, adicione uma secção commonLabels ao ficheiro de personalização base:

   cat <<EOF >> config/base/kustomization.yaml
   commonLabels:
     owner: myself
   EOF
   

2. Crie a configuração completa do Kubernetes e observe que a etiqueta owner já está presente:

   kubectl kustomize config/prod
   

3. Volte a executar o pipeline de CI com o Cloud Build:

   gcloud builds submit .
   

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

   [...]
   Step #2 - "Validate against policies": [RUNNING] "gcr.io/kpt-fn/gatekeeper:v0"
   Step #2 - "Validate against policies": [PASS] "gcr.io/kpt-fn/gatekeeper:v0"
   [...]
   

Sugestão: pode executar e depurar pipelines do Cloud Build localmente sem ter de acionar uma compilação real nem enviar para o seu repositório Git através do cloud-build-local.

Limpar

Atenção: a eliminação de um projeto tem os seguintes efeitos:

• Tudo no projeto é eliminado. Se usou um projeto existente para as tarefas neste documento, quando o elimina, também elimina qualquer outro trabalho que tenha feito no projeto.
• Os IDs dos projetos personalizados são perdidos. Quando criou este projeto, pode ter criado um ID do projeto personalizado que quer usar no futuro. Para preservar os URLs que usam o ID do projeto, como um URL appspot.com, elimine os recursos selecionados no projeto em vez de eliminar o projeto inteiro.

Se planeia explorar várias arquiteturas, tutoriais ou inícios rápidos, a reutilização de projetos pode ajudar a evitar exceder os limites de quota de projetos.

1. In the Google Cloud console, go to the Manage resources page.

   Go to Manage resources

2. In the project list, select the project that you want to delete, and then click Delete.
3. In the dialog, type the project ID, and then click Shut down to delete the project.