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 é obrigatório segui-los exatamente como prescrito. Cada universo do GDC tem requisitos e considerações exclusivas que precisam ser atendidas 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.

Por exemplo, sua empresa pode ter vários departamentos com organizações separadas, e cada uma delas 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 várias 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.

Outra possibilidade é que diferentes conjuntos de usuários usem 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 consolidar as identidades de usuário em um único provedor ou manter provedores separados funciona melhor com a abordagem da sua empresa para o gerenciamento de identidades.

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

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

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 personalizada de um serviço e 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ê realiza 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, não é necessário saber qual cluster subjacente realiza 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. Faça login usando as credenciais kubeconfig do cluster adequado 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 persistentes de conta de serviço para uso fora do GDC.
  • Conheça os 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 do token da conta de serviço das suas cargas de trabalho.
  • Alterne regularmente as credenciais da conta de serviço.

Considere 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 associações de função 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 do IAM do projeto em um único projeto a um usuário para que ele delegue autoridade para 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 de confiança, porque pode ser usado para aumentar privilégios, concedendo a si mesmo ou a outras pessoas papéis adicionais no projeto.

Faça auditorias regularmente para verificar se há privilégios excessivos

Revise os papéis concedidos na sua organização e faça uma auditoria para evitar privilégios excessivos. Verifique se os papéis concedidos são necessários para que um usuário individual conclua o trabalho dele e se as combinações de papéis em projetos não levam 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 funções altamente privilegiadas em várias organizações, já que isso pode violar o motivo da separação das organizações.