Configuração de autorizações de design

Este documento descreve as práticas recomendadas para a conceção de autorizações num universo isolado do Google Distributed Cloud (GDC). São abordados os seguintes tópicos:

Embora os seguintes designs sejam recomendados, não é obrigatório segui-los exatamente como prescrito. Cada universo do GDC tem requisitos e considerações únicos que têm de ser cumpridos caso a caso.

Configure um fornecedor de identidade por organização

Um operador tem de configurar um ou mais fornecedores de identidade por organização. Em seguida, um administrador liga-se a um fornecedor de identidade para gerir os serviços de autenticação para aplicações no universo do GDC.

Pode ter um cenário em que a sua empresa tem vários departamentos com organizações separadas e cada organização se liga ao mesmo fornecedor de identidade para autenticação. Nesse caso, é da sua responsabilidade compreender e auditar a combinação de privilégios que um utilizador tem em várias organizações. Certifique-se de que um utilizador com privilégios em várias organizações não viola os requisitos para separar as cargas de trabalho em organizações distintas.

Em alternativa, pode ter um cenário em que diferentes conjuntos de utilizadores usam fornecedores de identidade diferentes para autenticar numa única organização, como quando várias equipas de fornecedores trabalham em conjunto numa única organização. Considere se a consolidação das identidades dos utilizadores num único fornecedor de identidade ou a manutenção de fornecedores de identidade separados funciona melhor com a abordagem da sua empresa à gestão de identidades.

Configure a autenticação multifator para o seu fornecedor de identidade

O GDC depende da sua plataforma IAM para autenticação, incluindo definiçõ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 utilizador que possa aceder a recursos confidenciais.

Restrinja os serviços geridos e os serviços do Marketplace

Pode preferir bloquear alguns projetos de determinados serviços, para limitar a potencial superfície de ataque num projeto ou evitar a utilização de serviços não aprovados. Por predefinição, os serviços geridos, como a inteligência artificial e a aprendizagem automática, estão disponíveis para utilização em qualquer projeto. Em comparação com os serviços geridos, os serviços do Marketplace têm de ser ativados primeiro para a organização.

Para negar o acesso ao serviço a partir de projetos, aplique restrições do Gatekeeper à definição de recurso personalizado de um serviço e a uma lista de espaços de nomes. A abordagem para negar o acesso com o Gatekeeper aplica-se a serviços geridos e do Marketplace.

Faça a gestão de ficheiros kubeconfig para vários clusters

Diferentes tarefas operacionais requerem uma ligação a diferentes clusters. Por exemplo, realiza tarefas como associar uma função do IAM a um projeto e tarefas como implementar um recurso Pod do Kubernetes num cluster do Kubernetes.

Quando usa a consola do GDC, não precisa de saber que cluster subjacente realiza uma tarefa, uma vez que a consola do GDC abstrai as operações de baixo nível, como a ligação a um cluster.

No entanto, quando trabalha com a CLI gdcloud ou a CLI kubectl, pode ter vários ficheiros kubeconfig para concluir as suas tarefas. Certifique-se de que inicia sessão com as credenciais kubeconfig para o cluster adequado à sua tarefa.

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

Para as contas de serviço do Kubernetes, a autorização baseia-se num token secreto. Para mitigar o risco de tokens de contas de serviço, considere as seguintes práticas recomendadas:

  • Evite transferir credenciais de contas de serviço persistentes para utilização fora do GDC.
  • Tenha em atenção os caminhos de escalabilidade do Kubernetes para utilizadores ou contas de serviço que tenham a capacidade de criar e editar pods.
  • Defina o campo expirationSeconds para um período curto para a projeção de token da conta de serviço das suas cargas de trabalho.
  • Rode regularmente as credenciais da conta de serviço.

Considere o princípio do menor privilégio

Considere o princípio do menor privilégio (PoLP) ao conceder associações de funções aos utilizadores. De acordo com o PoLP, considere atribuir apenas os privilégios necessários para concluir uma tarefa.

Por exemplo, concede a função de administrador do IAM do projeto a um utilizador num único projeto, para que este utilizador delegue a autoridade para conceder funções nesse projeto. Em seguida, este utilizador concede funções detalhadas a outros programadores no projeto com base nos serviços específicos que usam. A função de administrador do IAM do projeto tem de ser restrita a um responsável fidedigno, uma vez que esta função pode ser usada para escalar privilégios, concedendo a si próprio ou a outras pessoas funções adicionais no projeto.

Audite regularmente para privilégios excessivos

Certifique-se de que revê as funções concedidas na sua organização e audita os privilégios excessivos. Tem de garantir que as funções concedidas são necessárias para um utilizador individual concluir o respetivo trabalho e que as combinações de funções em vários projetos não levam a um risco de escalabilidade ou exfiltração.

Se a sua empresa usar várias organizações, não recomendamos que um utilizador individual tenha funções com privilégios elevados em várias organizações, uma vez que tal pode violar o motivo da separação das organizações em primeiro lugar.