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). Os seguintes tópicos são abordados:

Embora os seguintes designs sejam recomendados, não é necessá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 estabelece ligação a um fornecedor de identidade para gerir os serviços de autenticação para aplicações no universo da 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 de separação de cargas de trabalho em organizações distintas.

Em alternativa, pode ter um cenário em que diferentes conjuntos de utilizadores usam diferentes fornecedores de identidade 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 baseia-se na sua plataforma IAM para a 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 sensíveis.

Restrinja os serviços geridos e os serviços de mercado

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 de mercado 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 recursos personalizados 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 mercado.

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

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

Quando usa a consola GDC, não precisa de saber que cluster subjacente executa uma tarefa, uma vez que a consola 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 realizar as suas tarefas. Certifique-se de que inicia sessão com as credenciais kubeconfig para o cluster adequado para a sua tarefa.

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

Para 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 persistentes da conta de serviço para utilização fora do GDC.
  • Tenha em atenção os caminhos de escalada do Kubernetes para utilizadores ou contas de serviço que podem criar e editar pods.
  • Defina o campo expirationSeconds para um período curto para a projeção do token da conta de serviço das suas cargas de trabalho.
  • Rode as credenciais da conta de serviço regularmente.

Considere o princípio do menor privilégio

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

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

Audite regularmente para verificar se existem privilégios excessivos

Certifique-se de que revê as funções concedidas na sua organização e audita-as em função do privilégio excessivo. Tem de garantir que as funções concedidas são necessárias para um utilizador individual concluir o seu trabalho e que as combinações de funções em vários projetos não originam um risco de escalada 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 isto pode violar o motivo da separação das organizações.