Criar políticas para um cluster multilocatário

Neste tutorial, mostramos como usar o Config Sync e o Kustomize para configurar políticas para namespaces em um cluster multilocatário.

No Kubernetes, um locatário pode ser uma equipe ou uma carga de trabalho. Para clusters multilocatários, a prática recomendada é criar um namespace para cada locatário. Em seguida, cada namespace poderá ter políticas adequadas às diferentes necessidades. Use o Config Sync para aplicar essas políticas de maneira consistente a cada locatário diferente.

Arquitetura do repositório

Neste tutorial, você configura o Config Sync para sincronizar com as configurações no diretório namespace-specific-policy/ do repositório de amostras do Anthos Config Management. Esse diretório contém os seguintes diretórios e arquivos:

├── configsync
│   ├── tenant-a
│   │   ├── ~g_v1_namespace_default.yaml
│   │   ├── networking.k8s.io_v1_networkpolicy_deny-all.yaml
│   │   ├── rbac.authorization.k8s.io_v1_rolebinding_tenant-admin-rolebinding.yaml
│   │   └── rbac.authorization.k8s.io_v1_role_tenant-admin.yaml
│   ├── tenant-b
│   │   ├── ~g_v1_namespace_default.yaml
│   │   ├── networking.k8s.io_v1_networkpolicy_deny-all.yaml
│   │   ├── rbac.authorization.k8s.io_v1_rolebinding_tenant-admin-rolebinding.yaml
│   │   └── rbac.authorization.k8s.io_v1_role_tenant-admin.yaml
│   └── tenant-c
│       ├── ~g_v1_namespace_default.yaml
│       ├── networking.k8s.io_v1_networkpolicy_deny-all.yaml
│       ├── rbac.authorization.k8s.io_v1_rolebinding_tenant-admin-rolebinding.yaml
│       └── rbac.authorization.k8s.io_v1_role_tenant-admin.yaml
├── configsync-src
│   ├── base
│   │   ├── kustomization.yaml
│   │   ├── namespace.yaml
│   │   ├── networkpolicy.yaml
│   │   ├── rolebinding.yaml
│   │   └── role.yaml
│   ├── tenant-a
│   │   └── kustomization.yaml
│   ├── tenant-b
│   │   └── kustomization.yaml
│   └── tenant-c
│       └── kustomization.yaml
├── README.md
└── scripts
    └── render.sh

Este repositório é um não estruturado. Isso proporciona flexibilidade para organizar as configurações da maneira que você quiser, o que é útil principalmente ao trabalhar com o Kustomize.

Nesse repositório, há três namespaces para três locatários diferentes: tenant-a, tenant-b e tenant-c. Cada um dos diretórios de namespace contém configurações para Roles, RoleBindings e NetworkPolicies. O diretório configsync- src contém a configuração no formato kustomize. O diretório configconfig-src contém a configuração no formato kustomize. Há uma base e três sobreposições tenant-a, tenant-b e tenant-c.

Objetivos

  • Atualizar uma sobreposição do Kustomize.

  • Criar um cluster que possa ser usado com o Config Sync.

  • Sincronizar as políticas no repositório Git com um cluster.

  • Verificar se o cluster está sincronizando com as configurações no repositório.

Custos

Neste tutorial, usamos os seguintes componentes faturáveis do Google Cloud:

Para gerar uma estimativa de custo baseada na projeção de uso deste tutorial, use a calculadora de preços. Novos usuários do Google Cloud podem estar qualificados para uma avaliação gratuita.

Ao concluir este tutorial, exclua os recursos criados para evitar o faturamento contínuo. Para mais informações, consulte Limpeza.

Antes de começar

Antes de iniciar este tutorial, conclua as seguintes tarefas:

  1. No Console do Google Cloud, na página do seletor de projetos, selecione ou crie um projeto do Google Cloud.

    Acessar o seletor de projetos

  2. Verifique se o faturamento está ativado para seu projeto na nuvem. Saiba como confirmar se o faturamento está ativado para o projeto.

  3. Crie ou tenha acesso a uma conta do GitHub.
  4. Instale o Kustomize executando o seguinte comando:

    gcloud components install kustomize
    

É útil ter alguma familiaridade com o Git e o Kustomize.

Atualizar um arquivo do Kustomize

Na seção a seguir, você atualiza um arquivo Kustomize no repositório para atualizar as políticas aplicadas a tenant-a.

Preparar o ambiente

Para preparar o ambiente, conclua as seguintes etapas:

  1. Bifurque o repositório:

    1. Acesse o repositório do diretório de amostras do Anthos Config Management no GitHub.
    2. Clique em Bifurcar.
  2. Clone o repositório bifurcado.

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

    Substitua GITHUB_USERNAME pelo nome de usuário do GitHub:

  3. Navegue até o diretório que contém os exemplos usados neste tutorial:

    cd anthos-config-management-samples/namespace-specific-policy
    

Atualize uma sobreposição

Nesta seção, você atualizará uma sobreposição. Uma sobreposição é uma personalização que depende de outra personalização.

As etapas a seguir mostram como conceder um novo papel a tenant-a atualizando a sobreposição dele. acm-samples/namespace-specific-policy/configsync-src/tenant-a. Como você está atualizando apenas uma configuração, só será necessário atualizar uma sobreposição.

Para dar tenant-a a esse novo papel, siga estas etapas:

  1. Crie um arquivo acessando a página a seguir no GitHub:

    github.com/GITHUB_USERNAME/anthos-config-management-samples/new/main/namespace-specific-policy/configsync-src/tenant-a
    
  2. Nomeie o arquivo another-role.yaml.

  3. Na janela Editar novo arquivo, cole o seguinte manifesto YAML para o novo papel:

    apiVersion: rbac.authorization.k8s.io/v1
    kind: Role
    metadata:
      name: pod-reader
    rules:
    - apiGroups: [""]
      resources: ["pods"]
      verbs: ["get", "watch", "list"]
    
  4. Clique em Confirmar novo arquivo.

    Agora é possível incluir a configuração do novo papel no arquivo kustomization.yaml.

  5. Na pasta /namespace-specific-policy/configsync-src/tenant-a, abra kustomization.yaml e clique no ícone de edição (parecido com um lápis).

  6. Na seção de recursos de kustomization.yaml, adicione - another-role.yaml:

    namespace: tenant-a
    
    resources:
    - ../base
    - another-role.yaml
    # The rest of the file is omitted
    
  7. Clique em Confirmar alterações.

  8. Após a atualização, recrie a saída do Kustomize para cada namespace executando o script render.sh:

    ./scripts/render.sh
    
  9. Confirme e envie a atualização:

    git add .
    git commit -m 'update configuration'
    git push
    

Criar e registrar um cluster do GKE

Nesta seção, você cria e configura um cluster que pode ser usado com o Config Sync.

Criar um cluster

Console

Para criar um cluster zonal com o Console do Google Cloud, execute as seguintes tarefas:

  1. Acesse o menu do Google Kubernetes Engine no Console do Cloud.

    Acessar o Google Kubernetes Engine

  2. Clique em Criar.

  3. Na seção Padrão, clique em Configurar.

  4. Na seção Princípios básicos do cluster, conclua o seguinte:

    1. Insira mt-cluster como o Nome do cluster.
    2. Na lista suspensa Zona, selecione us-central1-c.
    3. Não altere os outros campos.
  5. No menu à esquerda, clique em default-pool e, na lista suspensa exibida, clique em Nós.

  6. Na seção Programação, faça o seguinte:

    1. Na lista suspensa Tipo de máquina, selecione e2-standard-4.
    2. Mantenha os valores padrão em todos os outros campos.
  7. No menu à esquerda, selecione Segurança.

  8. Na seção Segurança, marque a caixa de seleção Ativar Identidade da carga de trabalho.

  9. Clique em Criar. A criação do cluster pode levar alguns minutos.

gcloud

Para criar um cluster com a ferramenta de linha de comando gcloud, execute a seguinte tarefa:

gcloud container clusters create mt-cluster \
    --project PROJECT_ID \
    --zone us-central1-c \
    --release-channel regular \
    --machine-type "e2-standard-4" \
    --workload-pool=PROJECT_ID.svc.id.goog

Substitua PROJECT_ID pela ID do seu projeto.

Receba as credenciais de autenticação para o cluster

Depois de criar o cluster, você precisará das credenciais de autenticação para interagir com o cluster:

gcloud container clusters get-credentials mt-cluster --zone us-central1-c

Conceda a si mesmo as permissões de administrador

Depois que o cluster for criado, conceda a si mesmo o papel Administrador do GKE Hub de que você precisa para o Config Sync.

Console

Para conceder a si mesmo permissões de administrador com o Console do Google Cloud, execute a seguinte tarefa:

  1. No Console do Cloud, acesse a página IAM.

    Acessar a página IAM

  2. Clique em Add.

  3. No campo Novos membros, digite um endereço de e-mail. É possível adicionar indivíduos, contas de serviço ou Grupos do Google como membros.

  4. Na lista suspensa Selecionar um papel, procure e selecione Administrador do GKE Hub.

  5. Clique em Save.

gcloud

Para conceder a si mesmo a permissão de administrador com a ferramenta de linha de comando gcloud, execute as seguintes tarefas:

gcloud projects add-iam-policy-binding PROJECT_ID \
    --member=MEMBER \
    --role=roles/gkehub.admin

Substitua:

  • PROJECT_ID: ID do projeto
  • MEMBER: um identificador do membro, que geralmente tem este formato: member-type:id Por exemplo, user:my-user@example.com. Para ver uma lista completa dos valores que member pode ter, consulte a referência de vinculação de políticas.

Registrar o cluster

Depois que o cluster for criado, é possível registrá-lo em uma frota:

Console

Para registrar o cluster com o Console do Google Cloud, execute as seguintes tarefas:

  1. No Console do Google Cloud, acesse a página Clusters do Anthos.

    Acessar a página de clusters do Anthos

  2. Clique em Registrar cluster existente.

  3. Ao lado de mt-cluster, clique em Registrar. Se você não encontrar esse cluster na lista, verifique se ele foi criado.

    Exemplo de saída:

    Cluster mt-cluster registered successfully as mt-cluster in project PROJECT_NAME.
    

gcloud

Para registrar o cluster com a ferramenta de linha de comando gcloud, execute a seguinte tarefa:

gcloud beta container hub memberships register MEMBERSHIP_NAME \
 --gke-cluster=us-central1-c/mt-cluster \
 --enable-workload-identity

Substitua:

  • MEMBERSHIP_NAME: o nome da assinatura que você escolhe para representar de maneira exclusiva o cluster que está sendo registrado na frota.

Configure o Config Sync

Nesta seção, você configura o Config Sync para que ele seja sincronizado com as políticas no diretório namespace-specific-policy/.

Para configurar o Config Sync, conclua as etapas a seguir.

Console

Para configurar o Config Sync com o Console do Google Cloud, execute as seguintes tarefas:

  1. No Console do Cloud, acesse a página Anthos Config Management.

    Acessar o Anthos Config Management

  2. Selecione mt-cluster e clique em Configurar.

  3. Na seção Autenticação do repositório do Git para ACM, selecione Nenhuma e clique em Continuar.

  4. Na seção Configurações do ACM para os clusters, faça o seguinte:

    1. No campo Versão, selecione uma versão 1.7 ou posterior.
    2. Marque a caixa de seleção Ativar Config Sync e preencha os seguintes campos:
      1. No campo URL, adicione https://github.com/GITHUB_USERNAME/anthos-config-management-samples
      2. No campo Ramificação, adicione main
      3. No campo Tag/Confirmação, adicione HEAD
      4. No campo Diretório de políticas, adicione namespace-specific-policy/configsync
      5. Deixe o campo Espera de sincronização em branco.
      6. Deixe o campo Proxy do Git em branco.
      7. Na lista suspensa Formato de origem, selecione não estruturado.
  5. Clique em Concluído. Você será redirecionado para a página Anthos Config Management. Após alguns minutos, você verá Synced na coluna de status ao lado do cluster configurado.

gcloud

Para configurar o Config Sync com a ferramenta de linha de comando gcloud, execute as seguintes tarefas:

  1. Crie um arquivo chamado apply-spec.yaml e copie o arquivo YAML a seguir nele.

    # apply-spec.yaml
    
    applySpecVersion: 1
    spec:
      configSync:
        # Set to true to install and enable Config Sync
        enabled: true
        sourceFormat: unstructured
        syncRepo: https://github.com/GITHUB_USERNAME/anthos-config-management-samples
        syncBranch: main
        secretType: none
        policyDir: namespace-specific-policy/configsync
    

    Substitua GITHUB_USERNAME pelo nome de usuário do GitHub:

  2. Aplique o arquivo apply-spec.yaml:

     gcloud beta container hub config-management apply \
         --membership=MEMBERSHIP_NAME \
         --config=CONFIG_YAML_PATH \
         --project=PROJECT_ID
    

    Substitua:

    • MEMBERSHIP_NAME: o nome da assinatura escolhido ao registrar o cluster, é possível encontrar o nome com gcloud container hub memberships list.
    • CONFIG_YAML_PATH: o caminho para o arquivo apply-spec.yaml
    • PROJECT_ID: o ID do projeto

Verificar se as políticas específicas do namespace estão sincronizadas

Agora que você instalou o Config Sync, verifique se as políticas específicas do namespace estão sincronizadas com o cluster usando o comando nomos status:

nomos status

O resultado será semelhante a:

gke_PROJECT_ID_us-central1-c_mt-cluster
  --------------------
  <root>   https:/github.com/GITHUB_USERNAME/anthos-config-management-samples/namespace-specific-policy/configsync@main
  SYNCED   bf8655aa
  Managed resources:
     NAMESPACE   NAME                                                             STATUS
                 namespace/foo                                                    Current
                 namespace/istio-system                                           Current
                 namespace/tenant-a                                               Current
                 namespace/tenant-b                                               Current
                 namespace/tenant-c                                               Current
     tenant-a    networkpolicy.networking.k8s.io/deny-all                         Current
     tenant-a    role.rbac.authorization.k8s.io/tenant-admin                      Current
     tenant-a    rolebinding.rbac.authorization.k8s.io/tenant-admin-rolebinding   Current
     tenant-b    networkpolicy.networking.k8s.io/deny-all                         Current
     tenant-b    role.rbac.authorization.k8s.io/tenant-admin                      Current
     tenant-b    rolebinding.rbac.authorization.k8s.io/tenant-admin-rolebinding   Current
     tenant-c    networkpolicy.networking.k8s.io/deny-all                         Current
     tenant-c    role.rbac.authorization.k8s.io/tenant-admin                      Current
     tenant-c    rolebinding.rbac.authorization.k8s.io/tenant-admin-rolebinding   Current

Em seguida, confirme se os recursos existem no cluster. Os exemplos a seguir mostram como verificar alguns dos recursos de tenant-a.

  1. Verifique se o RoleBinding para tenant-a existe:

    kubectl get RoleBinding/tenant-admin-rolebinding -n tenant-a
    

    Exemplo de saída:

    NAME                       ROLE                AGE
    tenant-admin-rolebinding   Role/tenant-admin   23h
    
  2. Verifique se o Role para tenant-a existe:

    kubectl get Role/tenant-admin -n tenant-a
    

    Exemplo de saída:

    NAME           CREATED AT
    tenant-admin   2021-05-24T21:49:06Z
    
  3. Verifique se a NetworkPolicy para tenant-a existe:

    kubectl get NetworkPolicy/deny-all -n tenant-a
    

    Exemplo de saída:

    NAME       POD-SELECTOR   AGE
    deny-all   <none>         23h
    

Ao usar esses comandos, é possível ver que cada namespace tem o próprio conjunto de políticas, seguindo a prática recomendada para clusters multilocatários.

Limpeza

Para evitar cobranças na sua conta do Google Cloud pelos recursos usados no tutorial, exclua o projeto que os contém ou mantenha o projeto e exclua os recursos individuais.

Exclua o projeto

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

    Acessar "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.

Exclua o diretório

Para limpar os namespaces e políticas do locatário para eles, recomendamos que você remova os diretórios que contêm a configuração do repositório Git:

rm -r acm-samples/namespace-specific-policy/configsync/tenant-*/*
git add .
git commit -m 'clean up'
git push

Quando a última confirmação do repositório raiz for sincronizada, os três namespaces tenant-a, tenant-b e tenant-c serão excluídos do cluster.

A seguir