Como usar o Policy Controller em um pipeline de CI

Esta página descreve como integrar o Policy Controller ao Cloud Build criando um pipeline de Integração Contínua (CI, na sigla em inglês) que verifica validações de política sincronizadas com um repositório Git.

Se você é um desenvolvedor e quiser validar seu app com relação às políticas da empresa, leia Como validar seu app em relação às políticas da empresa em um pipeline de integração contínua.

Introdução

A criação de um pipeline de CI com o Policy Controller permite:

  • impor configurações de política definidas e fornecer feedback aos desenvolvedores o mais rápido possível; as políticas permitem que os administradores da plataforma bloqueiem o acesso. As equipes de desenvolvimento precisam obedecer a essas políticas, em vez de removê-las ou contorná-las;

  • definir os campos padrão nos objetos Kubernetes que precisam sempre estar presentes. Por exemplo, você pode adicionar automaticamente rótulos para proprietários ou centro de custo.

Este documento se concentra em um pipeline de CI do Cloud Build usando um repositório de configuração do GitHub. Você pode usar o mesmo padrão para configurar outras ferramentas de CI ou sistemas de controle de versão compatíveis com o Anthos Config Management.

Esse pipeline é construído com funções KPT. As funções KPT permitem desenvolver imagens de contêiner do lado do cliente para validar, transformar ou gerar configurações do Kubernetes.

Este tópico usa funções KPT pré-criadas do Catálogo de funções KPT. Um subconjunto de funções no Catálogo foi espelhado para um Container Registry compatível com o Google e está disponível para todos os projetos.

Antes de começar

  • Você precisa ter um direito do Anthos para instalar o Policy Controller usando o Anthos Config Management.

  • Você precisa de um cluster com o Anthos Config Management já instalado.

  • Configure o Policy Controller.

  • Tenha a permissão serviceusage.services.enable no seu projeto do Google Cloud e servicemanagement.services.bind na API do Cloud Build. Essas permissões são necessárias para ativar a conta do serviço Cloud Build, veja mais detalhes em Como habilitar APIs.

  • Habilite o Cloud Build no seu projeto. Isso pode ser feito noConsole do Google Cloud.

Como usar um repositório não estruturado

Este tutorial inclui a opção de usar um repo não estruturado. Os repo não estruturados não requerem a estrutura de diretório do Anthos Config Management padrão.

Como configurar o Cloud Build

Você precisa conceder o papel "Desenvolvedor do Kubernetes Engine" à conta de serviço do Cloud Build em cada projeto em que configurar o pipeline.

  1. Abrir a página "Configurações do Cloud Build"

    A página Permissões da conta de serviço é exibida.

  2. Localize a linha que contém o Kubernetes Engine e defina o Status como Ativado.

Para mais informações, consulte Como definir permissões de conta de serviço.

Configurar o ambiente

Para configurar o Policy Controller para funcionar com o Cloud Build, consulte o exemplo de repo do Git.

Clone o repo com git.

git clone git@github.com:GoogleCloudPlatform/csp-config-management.git

Se você estiver usando um repositório hierárquico, precisará editar os arquivos de configuração neste repositório depois de configurar o Cloud Build.

Estrutura do diretório

No repo csp-config-management, há dois diretórios que contêm configs para um repo hierárquico (ci-pipeline/) e um repo não estruturado (ci-pipeline-unstructured/). Escolha o diretório apropriado para seu tipo de cluster.

Os diretórios ci-pipeline/ e ci-pipeline-unstructured/ no repositório usam a seguinte hierarquia:

  • config-root/ é a raiz do repositório e contém todos os configs deste exemplo.

  • config-root/.../*-constraint.yaml e *-template.yaml definem as restrições e os modelos do Policy Controller a que todas os configs em config-root/ precisam passar.

    Exemplo:

    • O arquivo ci-pipeline/config-root/cluster/required-labels-constraint.yaml requer que cada namespace tenha um rótulo cost-center.

    • O arquivo ci-pipeline-unstructured/config-root/constraints/banned-key-constraint.yaml impõe que nenhum Objeto ConfigMap contenha um campo chamado private-key.

    Para mais informações, consulte Como criar restrições.

  • cloudbuild.yaml é o arquivo de configuração do Cloud Build que define as etapas de build. Essas etapas do build são acionadas por uma confirmação no repositório.

    Usando um repo hierárquico, o pipeline cria o conteúdo do seu repo com nomos hydrate, concatena-os e valida-os com o Policy Controller.

    Em um repositório não estruturado, o Policy Controller cria sua configuração sem usar nomos ou conectar-se ao seu cluster.

    Para mais informações sobre o conteúdo de um arquivo de configuração, consulte Como criar uma configuração básica.

Como configurar o Cloud Build

Nesta seção, você conecta o Cloud Build ao seu repositório de origem para que o Cloud Build possa criar o código nesse repositório.

Como criar um acionador de versão

O Cloud Build executa gatilhos de construção quando uma confirmação é enviada para a ramificação. Para configurar um gatilho de criação no Console do Google Cloud, execute as seguintes etapas.

  1. Abra a página Gatilhos no Console do Google Cloud.

    Abrir a página Acionadores

  2. Selecione o projeto no menu suspenso do seletor na parte superior da página.

  3. Clique em Abrir.

  4. Clique em Criar gatilho.

  5. Crie um nome para seu gatilho.

  6. Para Evento, selecione Enviar para uma ramificação.

  7. Selecione seu Repositório. Se você não conectou seu repositório, execute as seguintes etapas:

    1. Clique em Conectar repositório.

    2. Selecione o repositório em que você armazenou seu código-fonte.

      Se você selecionar GitHub (espelhado) ou Bitbucket (espelhado) como seu repositório de origem, o Cloud Build espelhará seu repositório nos Cloud Source Repositories e utilizará o repositório espelhado.

    3. Clique em Continuar.

    4. Autentique o repositório de origem com seu nome de usuário e senha.

    5. Na lista de repositórios disponíveis, selecione o repositório que você quer e clique em Conectar repositório.

  8. Na lista de repositórios disponíveis, selecione o repositório csp-config-management.

  9. Selecione sua Ramificação, master.

  10. Em Configuração da compilação, defina seu Arquivo de configuração do Cloud Build como ci-pipeline/cloudbuild.yaml ou ci-pipeline-unstructured/cloudbuild.yaml.

  11. Clique em Criar para salvar o gatilho de compilação.

Você também pode criar gatilho de compilação com gcloud. Para mais informações, consulte Criando e gerenciando gatilhos de compilação.

Como configurar seu repositório

Depois que o Cloud Build estiver configurado para se conectar ao seu repo, conclua sua configuração para o Anthos Config Management.

  1. Edite o arquivo csp-config-management/CODEOWNERS e substitua @OWNER pelo seu nome de usuário do GitHub ou o alias de e-mail da equipe de administração da plataforma. Para saber mais sobre a sintaxe CODEOWNERS, consulte Sobre proprietários de códigos.

Selecione se você estiver usando um repositório hierárquico (padrão) ou não estruturado abaixo.

  1. Editar o arquivo de configuração

    Hierárquica

    Edite o arquivo csp-config-management/ci-pipeline/cloudbuild.yaml.

    Substitua CLUSTER_NAME e ZONE pelo nome e pela zona de um cluster GKE com o Anthos Config Management e o Policy Controller instalados.

    Não estruturado

    Nenhuma alteração de configuração é necessária com um repo não estruturado neste exemplo. O Anthos Config Management e o Policy Controller validam seu repo sem conectar seu cluster.

  2. Adicione e confirme suas alterações no repo.

    Hierárquica

    cd ci-pipeline
    git add .
    git commit -m "[COMMIT_MESSAGE]"

    Não estruturado

    cd ci-pipeline-unstructured
    git add .
    git commit -m "[COMMIT_MESSAGE]"

    Após a confirmação, o Cloud Build executa uma validação de política no repositório.

  3. Abra seu Histórico do Cloud Build e clique no Build mais recente.

    A página Detalhes do build é exibida.

  4. A amostra no repo csp-config-management contém um erro.

    Selecione o build mais recente no topo da lista, que inclui o ícone .

  5. A última etapa que o Cloud Build executa termina com um erro. O erro segue.

    Hierárquica

    Error: Found 1 violations:
    [1] All namespaces must have a cost-center label that points to your division
    name: "shipping-prod"
    path: namespace_shipping-prod.yaml

    Não estruturado

    Step #2: Error: Found 1 violations:
    [1] The following banned keys are being used in the config map: {"private_key"}
    name: "super-secret"
    path: configmap.yaml

  6. Em seguida, corrija o erro editando um arquivo em seu repositório.

    Hierárquica

    Edite o arquivo /ci-pipeline/config-root/namespaces/online/shipping-app-backend/shipping-prod/namespace.yaml e defina um valor para metadata.labels.cost-center. Seu namespace.yaml precisa ter a seguinte aparência:

    apiVersion: v1
    kind: Namespace
    metadata:
      name: shipping-prod
      labels:
        env: prod
        cost-center: "shipping.foo-corp.com"
      annotations:
        audit: "true"
    

    Não estruturado

    Edite o arquivo /ci-pipeline-unstructured/config-root/configmap.yaml. Altere o campo chamado data.private_key para data.public_key. Seu YAML editado se parece com o seguinte.

    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: super-secret
      namespace: default
    data:
      public_key: no secrets here
    

    Em seguida, confirme e envie suas alterações.

    git add .
    git commit -m "[COMMIT_MESSAGE]"
    git push origin [BRANCH]
  7. Abra seu Histórico do Cloud Build e clique no Build mais recente.

    A página Detalhes do build é exibida.

  8. Seu novo build precisa ser Bem-sucedido.

Resolver problemas

Problema: o build do My Cloud Build falha e o histórico inclui o seguinte erro.

  [1] KNV1021: No CustomResourceDefinition is defined for the type "ConstraintTemplate.templates.gatekeeper.sh" in the cluster.
  Resource types that are not native Kubernetes objects must have a CustomResourceDefinition.

Solução: confirme sua instalação do Policy Controller.

A seguir