Configuração de permissões de design

Neste documento, descrevemos as práticas recomendadas para o design de permissões em um universo do Google Distributed Cloud (GDC) com isolamento físico. Os seguintes tópicos são abordados:

Embora os designs a seguir sejam recomendados, não é obrigató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 os serviços de autenticação de aplicativos no universo do GDC.

Talvez sua empresa tenha vários departamentos com organizações separadas, e cada organização se conecte 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, talvez você tenha um cenário em que diferentes conjuntos de usuários usam provedores de identidade diferentes para autenticação 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 identidade.

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

O GDC depende da sua plataforma do IAM para autenticação, incluindo outras configurações de segurança, como 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 serviços 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, serviços gerenciados como inteligência artificial e machine learning 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 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ê executa tarefas como vincular um papel do IAM a um projeto e implantar um recurso Pod do Kubernetes em um cluster do Kubernetes.

Ao usar o console do GDC, você não precisa 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, talvez você tenha vários arquivos kubeconfig para realizar suas tarefas. Faça login usando as credenciais do 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 mitigar 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 podem 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 suas 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 aos 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 de Projetos do IAM em um único projeto a um usuário para que ele delegue autoridade para conceder papéis nesse projeto. 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 projeto do IAM precisa ser restrito a um líder confiável, porque ele pode ser usado para escalonar privilégios, concedendo a si mesmo ou a outras pessoas papéis adicionais no projeto.

Auditar regularmente para identificar privilégios excessivos

Revise os papéis concedidos na sua organização e faça uma auditoria para evitar privilégios excessivos. É preciso 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 a empresa usa várias organizações, não recomendamos que um usuário individual tenha papéis com muitos privilégios em várias organizações, porque isso pode violar o motivo de separar as organizações.