Configuração de permissões de design

Este documento descreve as práticas recomendadas para o design de permissões em um universo isolado do Google Distributed Cloud (GDC). Os seguintes tópicos são abordados:

Embora os designs a seguir sejam recomendados, não é necessário segui-los exatamente como prescrito. Cada universo do GDC tem requisitos e considerações exclusivos que precisam ser atendidos caso a caso.

Configurar um provedor de identidade por organização

Um operador precisa configurar um ou mais provedores de identidade por organização. Em seguida, um administrador se conecta a um provedor de identidade para gerenciar serviços de autenticação para aplicativos no universo do GDC.

Pode haver um cenário em que sua empresa tenha vários departamentos com organizações separadas, e cada organização se conecta ao mesmo provedor de identidade para autenticação. Nesse caso, é sua responsabilidade entender e auditar a combinação de privilégios que um usuário tem em todas as organizações. Verifique se um usuário com privilégios em várias organizações não viola os requisitos para separar cargas de trabalho em organizações distintas.

Como alternativa, você pode ter um cenário em que diferentes conjuntos de usuários usam provedores de identidade diferentes para autenticar em uma única organização, como quando várias equipes de fornecedores trabalham juntas em uma única organização. Considere se a consolidação de identidades de usuário em um único provedor de identidade ou a manutenção de provedores de identidade separados funciona melhor com a abordagem da sua empresa para o gerenciamento de identidades.

Configurar a autenticação multifator para o provedor de identidade

O GDC depende da plataforma do IAM para autenticação, incluindo configurações de segurança adicionais, como a autenticação multifator. É uma boa prática configurar a autenticação multifator com uma chave física para qualquer usuário que possa acessar recursos confidenciais.

Restringir serviços gerenciados e do marketplace

Talvez você prefira bloquear alguns projetos de determinados serviços para limitar a possível superfície de ataque em um projeto ou evitar o uso de serviços não aprovados. Por padrão, os serviços gerenciados, como inteligência artificial e aprendizado de máquina, estão disponíveis para uso em qualquer projeto. Em comparação com os serviços gerenciados, os serviços do marketplace precisam ser ativados primeiro para a organização.

Para negar o acesso ao serviço de projetos, aplique restrições do Gatekeeper à definição de recurso personalizado de um serviço e a uma lista de namespaces. A abordagem para negar o acesso com o Gatekeeper se aplica a serviços gerenciados e do marketplace.

Gerenciar arquivos kubeconfig para vários clusters

Diferentes tarefas operacionais exigem uma conexão com clusters diferentes. Por exemplo, você realiza tarefas como vincular um papel do IAM a um projeto e tarefas como implantar um recurso Pod do Kubernetes em um cluster do Kubernetes.

Ao usar o console do GDC, não é necessário saber qual cluster subjacente executa uma tarefa, já que o console do GDC abstrai as operações de baixo nível, como a conexão a um cluster.

No entanto, ao trabalhar com a CLI gdcloud ou kubectl, você pode ter vários arquivos kubeconfig para realizar suas tarefas. Certifique-se de que você faça login usando as credenciais kubeconfig para o cluster apropriado para sua tarefa.

Práticas recomendadas para contas de serviço do Kubernetes

Para contas de serviço do Kubernetes, a autorização é baseada em um token secreto. Para reduzir o risco de tokens de conta de serviço, considere as seguintes práticas recomendadas:

  • Evite fazer o download de credenciais de conta de serviço persistentes para uso fora do GDC.
  • Esteja ciente dos caminhos de escalonamento do Kubernetes para usuários ou contas de serviço que têm a capacidade de criar e editar pods.
  • Defina o campo expirationSeconds como um período curto para a projeção de token da conta de serviço das cargas de trabalho.
  • Faça a rotação das credenciais da conta de serviço regularmente.

Considerar o princípio de privilégio mínimo

Considere o princípio de privilégio mínimo (PoLP, na sigla em inglês) ao conceder vinculações de papéis a usuários. De acordo com o PoLP, considere atribuir apenas os privilégios necessários para concluir uma tarefa.

Por exemplo, você concede o papel de administrador do IAM do projeto em um único projeto a um usuário para que ele delegue a autoridade de conceder papéis nesse projeto. Em seguida, esse usuário concede papéis granulares a outros desenvolvedores no projeto com base nos serviços específicos que eles usam. O papel de administrador do IAM do projeto precisa ser restrito a um líder confiável, porque ele pode ser usado para aumentar o privilégio, concedendo a si mesmo ou a outros papéis adicionais no projeto.

Auditar regularmente para privilégios excessivos

Revise os papéis concedidos na sua organização e audite os privilégios excessivos. É necessário garantir que os papéis concedidos sejam necessários para que um usuário individual conclua o trabalho e que as combinações de papéis em projetos não levem a um risco de escalonamento ou exfiltração.

Se sua empresa usa várias organizações, não recomendamos que um usuário individual tenha papéis altamente privilegiados em várias organizações, já que isso pode violar o motivo da separação das organizações.