Práticas recomendadas para o gerenciamento de políticas com o Anthos Config Management e o GitLab

Neste documento, você verá como usar o Anthos Config Management e o GitLab para gerenciar vários clusters do Kubernetes em um ambiente de produção. Proteger o repositório do Anthos Config Management é um passo importante da implantação, e usar este documento ajuda nesse processo. Com este documento, você implanta o Anthos Config Management para uso em produção. Para isso, é necessário que você se familiarize com o Kubernetes e o Git.

Se você estiver operando uma plataforma que hospeda apps para sua organização, é importante ter políticas para facilitar a proteção dela. As políticas são regras que visam proteger a plataforma e os apps e dados nela. A plataforma cumpre essas políticas com base em configurações que as descrevem. Isso melhora a segurança e a estabilidade da plataforma.

Com o Anthos Config Management, você gerencia políticas em escala para plataformas criadas no Google Kubernetes Engine (GKE), Anthos GKE ou outras distribuições Kubernetes. Com o Anthos Config Management, você cria e gerencia objetos do Kubernetes em vários clusters de uma só vez. É possível gerenciar qualquer objeto do Kubernetes com o Anthos Config Management, mas é melhor aplicar políticas como as seguintes:

  • PodSecurityPolicies: impede que os pods usem o usuário raiz do Linux.
  • NetworkPolicies: controla o tráfego de rede dentro dos clusters.
  • ClusterRoles e ClusterRoleBindings: controlam as permissões dentro de um cluster.

Conforme mostrado no diagrama a seguir, o Anthos Config Management é uma ferramenta no estilo GitOps (em inglês). Ele usa um repositório Git como mecanismo de armazenamento e fonte da verdade.

Arquitetura da configuração do Kubernetes no Git.

Com o Anthos Config Management, é possível implantar e gerenciar objetos do Kubernetes interagindo com esse repositório Git. Ter acesso de gravação à ramificação principal do repositório Git do Anthos Config Management significa ser um administrador dos clusters que o Anthos Config Management gerencia. O repositório do Anthos Config Management contém informações úteis para um possível invasor. Portanto, é importante protegê-lo.

Neste documento, você verá o uso do GitLab Source Code Management (SCM), link em inglês como um serviço de hospedagem do repositório Git e a descrição das práticas recomendadas para usar o Anthos Config Management e o GitLab juntos para gerenciar vários clusters do Kubernetes.

O Anthos Config Management e a arquitetura GitLab

No diagrama a seguir, você verá a arquitetura de implantação do Anthos Config Management com o GitLab para gerenciar três clusters do Kubernetes: um no GKE, um no GKE On-Prem e outro em um provedor de nuvem.

Arquitetura de implantação do Anthos Config Management com o GitLab.

O diagrama anterior ilustra as seguintes etapas no pipeline:

  1. Para fazer uma alteração de configuração em um ou todos os clusters, um usuário envia uma modificação, chamada solicitação de mesclagem (MR, na sigla em inglês), em inglês, que precisa ser validada no GitLab.
  2. A MR aciona um pipeline automático pelo CI/CD do GitLab (em inglês), o sistema de integração e entrega contínua incorporado ao GitLab, para testar e validar a configuração.
  3. A MR é aprovada ou rejeitada por um administrador. Após a aprovação, a alteração é mesclada no repositório Git.
  4. Após a aprovação, os agentes do Anthos Config Management que estão em execução em cada cluster leem essa modificação do GitLab e a aplicam ao cluster.

Práticas recomendadas de hospedagem do GitLab no contexto do Anthos Config Management

Nesta seção, você verá as práticas recomendadas a serem seguidas ao usar o SCM do GitLab para hospedar e gerenciar os repositórios do Anthos Config Management. As práticas recomendadas gerais para hospedar o GitLab, como configurar uma arquitetura altamente disponível e backups regulares, também se aplicam, mas estão fora do escopo deste documento (páginas em inglês).

Restringir o acesso administrativo

Qualquer pessoa com acesso raiz à máquina virtual (ou cluster do Kubernetes) que hospede o GitLab pode ignorar os recursos de segurança dele e, portanto, precisa ser considerado um administrador do Anthos Config Management. Essa suposição também é válida para qualquer pessoa que seja administrador no GitLab ou qualquer pessoa com acesso de gravação ao banco de dados do GitLab. Se você conceder às pessoas privilégio de administrador do GitLab, acesso raiz à máquina virtual (ou cluster do Kubernetes) que o hospeda ou acesso ao banco de dados dele, elas também poderão fazer alterações no Anthos Config Management. Para mais informações, consulte a documentação Permissões do GitLab (em inglês).

Se você estiver usando o Compute Engine, use o gerenciamento de identidade e acesso (IAM) e o Login do SO para controlar quem tem acesso à instância. Em particular, o papel do login de administrador no SO do Compute concede acesso raiz à instância.

Se você estiver usando o GKE, use o IAM e o RBAC para controlar quem pode acessar o cluster.

Ser cuidadoso com as atualizações

O GitLab tem um lançamento por mês e vários lançamentos de patch entre cada um deles. Como qualquer software, o GitLab fornece patches de segurança em alguns desses lançamentos. Por esse motivo, mantenha a instância do GitLab o mais atualizada possível. Para mais informações, consulte Como atualizar o GitLab (em inglês).

Seguir as práticas recomendadas específicas do Google Cloud para hospedar o GitLab nele

Se você hospedar o GitLab no Google Cloud, dedique um projeto do Cloud a ele. Coloque esse projeto diretamente no nó da organização, não em uma pasta. Essas recomendações podem reduzir a probabilidade das seguintes configurações incorretas do IAM:

  • Se o GitLab compartilhar um projeto do Cloud com outros apps e você conceder acesso a eles, haverá risco de o acesso administrativo ser concedido acidentalmente ao GitLab.
  • Se você colocar esse projeto do Cloud em uma pasta e conceder acesso a ela, corre o risco de conceder acesso a esse projeto acidentalmente.

Se você estiver implantando o GitLab no Google Cloud, também recomendamos que aproveite os serviços gerenciados a seguir:

  • Use o Cloud SQL para PostgreSQL para hospedar o banco de dados do GitLab. O Cloud SQL cuida da alta disponibilidade e dos backups para você.
  • Use o Memorystore para Redis como o servidor GitLab Redis. O Memorystore cuida da alta disponibilidade para você.
  • Use o Cloud Storage para armazenar backups, artefatos de build e uploads de usuários.

Para mais informações, consulte Como implantar o GitLab pronto para produção no Google Kubernetes Engine.

Autenticação e controle de acesso para o GitLab

Para fins de auditoria ou depuração, é importante identificar quem fez uma alteração na política e que as identidades também são usadas pela equipe de TI para gerenciar vários recursos.

Usar identidades unificadas

Por padrão, você interage com o Anthos Config Management por meio de um repositório Git em que você cria, atualiza e exclui recursos. No repositório Git, você controla quais usuários podem fazer o que e onde é possível controlar todas as atividades. Implementar o controle de acesso e a auditoria fica mais fácil se as identidades usadas por seus funcionários forem as mesmas em todos os lugares: no Google Cloud, no GitLab e nos seus sistemas locais. As identidades unificadas permitem que você faça referência às permissões e os registros de auditoria em diferentes sistemas.

No GitLab, é possível controlar eventos de auditoria em grupos, projetos e instâncias e consultar os registros do sistema para eventos de nível de serviço do GitLab (links em inglês). Os recursos de eventos de auditoria do GitLab abrangem níveis licenciados para empresas.

Se você não estiver usando o Google como um provedor de identidade

É possível aliar o Google Cloud com muitos dos IdPs conhecidos, como o Active Directory, o Azure Active Directory ou Okta (links em inglês). Também é possível configurar o GitLab para usar o Active Directory ou o Okta (links em inglês).

Se você estiver usando o Google como um provedor de identidade

Se você estiver usando o Google como um provedor de identidade, é possível usar o Provedor OmniAuth do Google OAuth 2.0 ou o LDAP seguro (links em inglês). No entanto, se você quiser sincronizar grupos com o GitLab, conforme recomendado na próxima seção, precisará usar o LDAP seguro. O LDAP seguro está disponível no Cloud Identity Premium e no Google Workspace Enterprise. Para mais informações, consulte Sobre o serviço do LDAP seguro.

Sincronizar grupos com o GitLab

Independentemente da tecnologia usada para identificar seus usuários, é útil agrupá-los para configurar seus acessos. Os grupos permitem que você pense nesses usuários em um nível superior ao conceder permissões: "eu concedo acesso administrativo aos ambientes de produção ao meu grupo de operações", em vez de "eu concedo acesso administrativo aos ambientes de produção a Alice, Bob, Claudia e Dinesh". Se os processos de Recursos Humanos estiverem bem integrados aos sistemas de TI, a associação ao grupo também será gerenciada automaticamente quando um funcionário for contratado, sair da empresa ou mudar de cargo. Se você estiver usando grupos, essa integração significa que geralmente não é necessário atualizar suas configurações de controle de acesso.

Como o Anthos Config Management é um sistema confidencial, é importante contar com grupos de usuários para controlar o acesso a ele. No GitLab, é possível compartilhar um projeto com um grupo de usuários (em inglês) e especificar o nível de acesso dos membros desse grupo.

Aplicar autenticação de dois fatores

Use a 2FA, também conhecida como autenticação de dois fatores, para melhorar a segurança da sua organização. Credenciais roubadas e ataques de phishing são dois vetores de ataque comuns. A 2FA protege contra ambos. Devido à natureza confidencial do repositório Git do Anthos Config Management, as contas dos usuários que interagem com ele precisam ser o mais protegidas possível, o que significa ativar a 2FA para esses usuários.

Se você configurar o Logon único (SSO) para o GitLab, precisará aplicar a 2FA ao provedor de SSO. Se você usar o Google como um provedor de SSO, será possível ativar a 2FA.

Se você não tiver configurado o SSO para o GitLab, será possível aplicar a 2FA diretamente no GitLab (em inglês).

Usar chaves de implantação para conectar os agentes do Anthos Config Management ao GitLab

Conforme descrito no documento Como instalar o Anthos Config Management, é possível conectar os agentes do Anthos Config Management ao repositório usando os métodos comuns para Git: HTTP(s) ou SSH. Se você usa HTTP(s) para acessar repositórios hospedados no GitLab, não use uma conta de usuário, porque isso pode causar problemas como licenciamento e usuários que usam as próprias contas para configurar o Anthos Config Management. Implantar chaves e tokens de implantação do GitLab são uma alternativa melhor. Uma chave de implantação é uma chave SSH que não está vinculada a um usuário específico, mas que sistemas automatizados podem usar para executar operações Git, que é o tipo de acesso seguro que o Anthos Config Management precisa. Um token de implantação tem o mesmo uso de uma chave de implantação, mas é possível usá-lo para autenticar por HTTP(s) em vez de SSH.

As chaves e tokens de implantação exclusivos permitem controlar e revogar o acesso dos agentes do Anthos Config Management ao repositório Git por cluster. Evite usar chaves de implantação globais para o Anthos Config Management e tokens de implantação em grupo. Use-os para outros fins além do Anthos Config Management, gerando efeitos indesejados se a configuração for alterada.

Gerenciar quem pode aprovar solicitações de mesclagem

Por padrão, o GitLab usa papéis para conceder permissões (em inglês) em projetos do GitLab. Por exemplo, um usuário com o papel de desenvolvedor pode abrir uma solicitação de mesclagem e um usuário com o papel de mantenedor pode aprovar a solicitação. Ainda que esse sistema de permissões funcione bem no início para o Anthos Config Management, é possível que ocorram problemas à medida que seu Kubernetes e Anthos Config Management aumentam. Os mantenedores do repositório do Anthos Config Management podem ficar sobrecarregados pelo número de solicitações de mesclagem que precisam processar e aprovar.

Aproveite os recursos Premium do GitLab para ajudar nesse problema:

  • Use os Proprietários de código (em inglês) para conceder permissões em um arquivo ou diretório. Esse recurso é útil porque o Anthos Config Management usa uma estrutura de diretórios para descrever clusters e namespaces. Usando os proprietários de código, é possível conceder permissões de aprovação em um namespace específico em todos os clusters, por exemplo.
  • Use as aprovações de solicitação de mesclagem (em inglês) para solicitar que pessoas diferentes de equipes diferentes aprovem uma solicitação antes que ela seja mesclada. Por exemplo, é possível exigir dois aprovadores, alguém da equipe de operações e alguém da equipe de segurança, para aprovar uma solicitação de mesclagem.

No diagrama a seguir, você verá a divisão técnica de uma organização e um exemplo de como a delegação de aprovação pode funcionar em um ambiente de produção.

Exemplo de arquitetura da hierarquia em uma organização.

O diagrama anterior tem um diretor técnico executivo (CTO, na sigla em inglês) com várias equipes que se reportam a ele: uma equipe de segurança, uma equipe de plataforma e várias equipes de app.

O repositório Git do Anthos Config Management dessa organização tem a seguinte estrutura (mostrando apenas diretórios, não arquivos):

.
├─ system
├─ clusterregistry
├─ cluster
└─ namespaces
   ├─ cicd
   ├─ audit
   └─ applications
      ├─ team-a
      └─ team-b

Para mais informações sobre cada diretório, consulte Como usar o repo do Anthos Config Management.

Com essa estrutura, a organização pode usar os recursos do GitLab mencionados anteriormente para implementar o processo a seguir:

  • Qualquer modificação na raiz do repositório ou no diretório system precisa ser aprovada pelo CTO.
  • Qualquer modificação no diretório clusterregistry precisa ser aprovada por um membro da equipe da plataforma.
  • Qualquer modificação no diretório cluster precisa ser aprovada por um membro da equipe da plataforma e por um membro da equipe de segurança.
  • Qualquer modificação no diretório namespaces precisa ser aprovada por um membro da equipe da plataforma.
  • Qualquer modificação nos subdiretórios no diretório namespaces precisa ser aprovada pelas equipes a seguir:

    • O subdiretório cicd representa um namespace dedicado às ferramentas de integração contínua e entrega contínua (CI/CD). Qualquer alteração precisa ser aprovada por um membro da equipe da plataforma.
    • O subdiretório audit representa um namespace dedicado às ferramentas de auditoria. Qualquer alteração precisa ser aprovada por um membro da equipe de segurança.
    • O subdiretório applications contém todos os recursos criados para cada namespace de app. Qualquer alteração precisa ser aprovada por um membro da equipe da plataforma e por um membro da equipe de segurança.
    • Os subdiretórios team-a e team-b representam os namespaces dedicados às equipes A e B. Qualquer alteração precisa ser aprovada pelo líder dessa equipe.

A implementação desse processo é mais fácil se os grupos do seu Provedor de Identidade forem sincronizados com o GitLab do que se eles não forem sincronizados. É possível exigir várias aprovações de grupos diferentes para uma solicitação de mesclagem. Para mais informações, consulte Sincronizar grupos com o GitLab e Como editar aprovações (em inglês).

Desativar executores compartilhados

Use o GitLab CI para testar automaticamente as políticas do Anthos Config Management antes de implantá-las. O GitLab CI usa executores (em inglês) para realizar os jobs que você quer. Esses executores podem ser compartilhados com toda a instância do GitLab. Nesse caso, eles são mantidos pela mesma equipe dessa instância ou dedicados a grupos ou projetos do GitLab.

Devido à natureza confidencial do repositório do Anthos Config Management, evite usar executores compartilhados para testar o código do Anthos Config Management. Em vez disso, use os executores que são dedicados aos projetos do Anthos Config Management e que são mantidos pelas pessoas que podem aprovar solicitações de mesclagem.

Resumo das recomendações

Nesta seção, resumimos as recomendações das seções anteriores. Se você usa o GitLab para hospedar o repositório Git do Anthos Config Management, recomendamos que você faça o seguinte:

  • Estabeleça o controle sobre quem tem acesso administrativo ao GitLab, porque essas pessoas também têm acesso administrativo ao Anthos Config Management.
  • Atualize o GitLab regularmente e sempre que um patch de segurança for lançado.
  • Dedique um projeto do Cloud ao GitLab no nó da organização se você hospedar o GitLab no Google Cloud.
  • Configure todos os seus sistemas, incluindo o GitLab, para usar o mesmo provedor de identidade.
  • Se possível, sincronize seus grupos de usuários atuais com o GitLab usando o recurso de Sincronização de grupo LDAP (em inglês), que é um recurso licenciado da GitLab Enterprise.
  • Aplique a 2FA aos usuários que interagem com o Anthos Config Management para aumentar a proteção contra problemas de credenciais roubadas e phishing.
  • Ao configurar os agentes do Anthos Config Management, faça o seguinte:
    • Configure os agentes do Anthos Config Management para usar SSH e implantar chaves ou HTTPS e implantar tokens para se conectar ao GitLab.
    • Evite usar HTTP não criptografado.
    • Crie uma chave de implantação exclusiva por cluster do Kubernetes no seu repositório do Anthos Config Management.
    • Configure as chaves e os tokens de implantação diretamente no repositório do Anthos Config Management e evite usar chaves de implantação globais e tokens de implantação de grupo para o Anthos Config Management.
  • Fique atento a atrasos na aprovação de solicitações de mesclagem no repositório do Anthos Config Management. Se você perceber que eles estão aumentando de forma excessiva, use os Proprietários de código ou as aprovações avançadas de solicitação de mesclagem para conceder permissões de aprovação a mais pessoas em sua organização (links em inglês).
  • Desative os executores compartilhados (em inglês) no seu projeto do Anthos Config Management e use somente os executores dedicados a este projeto.

A seguir