Controle de acesso

Este documento descreve as diferenças entre Identity and Access Management (IAM) e o controle de acesso baseado em papéis (RBAC, na sigla em inglês) do Kubernetes no Google Kubernetes Engine para ajudar você a gerenciar o acesso aos recursos no seu projeto. Este documento pressupõe que você conheça o seguinte:

Este documento é destinado a especialistas em segurança que controlam o acesso a permissões e querem entender as diferenças e a sobreposição entre o IAM e o RBAC. Para saber mais sobre papéis comuns e tarefas de exemplo que mencionamos no conteúdo doGoogle Cloud , consulte Funções e tarefas comuns do usuário do GKE.

Gerenciar o acesso aos recursos do GKE

Ao criar um Google Cloud projeto, você é o único usuário dele. Por padrão, nenhum outro usuário tem acesso ao seu projeto ou recursos dele, incluindo os recursos do Google Kubernetes Engine (GKE). O GKE é compatível com várias opções para gerenciar o acesso a recursos no projeto e nos clusters dele usando o controle de acesso baseado em papéis (RBAC, na sigla em inglês).

Esses mecanismos têm algumas funções semelhantes, mas são direcionados para diferentes tipos de recursos. Cada um é explicado em uma seção dedicada nesta página. No entanto, estas são algumas características:

  • O RBAC do Kubernetes é incorporado ao Kubernetes e concede permissões granulares a objetos nos clusters do Kubernetes. As permissões existem como objetos ClusterRole ou Role no cluster. Os objetos RoleBinding concedem papéis a usuários do Kubernetes, usuários do Google Cloud , contas de serviço do IAM ou Grupos do Google.

    Se você usa principalmente o GKE e precisa de permissões refinadas para cada objeto e operação no cluster, o RBAC do Kubernetes é a melhor escolha.

  • O IAM gerencia recursos do Google Cloud , incluindo clusters e tipos de objetos dentro deles. As permissões são atribuídas aos principais do IAM.

    Não há mecanismo para conceder permissões a objetos específicos do Kubernetes no IAM. Por exemplo, é possível conceder permissão a um usuário para criar CustomResourceDefinitions (CRDs). No entanto, isso não é possível para criar somente uma CustomResourceDefinition em particular ou limitar a produção a um namespace individual ou a um cluster especial no projeto. Se aplicado no nível da pasta, um papel do IAM concede privilégios a todos os clusters no projeto ou em todos os projetos filho.

    Se você usa vários componentes do Google Cloud e não precisa gerenciar permissões granulares específicas do Kubernetes, o IAM é uma boa opção.

Kubernetes RBAC

O Kubernetes conta com suporte integrado para RBAC, o que permite criar papéis específicos que existem no cluster do Kubernetes. É possível definir o escopo de um papel para um objeto específico do Kubernetes ou um tipo de objeto do Kubernetes. Também é possível definir quais ações (chamadas de verbos) o papel concede em relação a esse objeto. Um RoleBinding também é um objeto do Kubernetes que concede papéis aos usuários. Em um usuário do GKE, pode ser qualquer um dos seguintes:

  • Google Cloud user
  • Conta de serviço do IAM
  • Conta de serviço do Kubernetes
  • Google Workspace User
  • Grupos do Google do Google Workspace
  • Usuários autenticados com certificados do cliente X509

Para saber mais, consulte Controle de acesso baseado em papel.

IAM

O IAM permite conceder papéis a principais. Um papel é um conjunto de permissões e, quando concedido a um principal, permite que ele acesse um ou mais Google Cloud recursos. Para mais informações sobre principais, papéis e outros termos do IAM, consulte a visão geral do IAM.

No GKE, um principal pode ser qualquer um dos seguintes:

  • Conta de usuário
  • Conta de serviço
  • Grupos do Google do Google Workspace
  • Domínio do Google Workspace
  • Domínio do Cloud Identity

Para mais informações sobre como usar o IAM para controlar o acesso no GKE, consulte Criar políticas de permissão do IAM.

Tipos de políticas do IAM

O IAM aceita os seguintes tipos de políticas:

  • Permitir políticas: atribua papéis aos principais. Para detalhes, consulte a Política de permissão.
  • Políticas de negação: impedem que os principais usem permissões específicas do IAM, independentemente dos papéis atribuídos a eles. Para mais detalhes, consulte as Políticas de negação.

Use as políticas de negação para impedir que principais específicos executem ações específicas no projeto, pasta ou organização, mesmo que uma política de permissão do IAM conceda a esses principais um papel que contenha as permissões relevantes.

Recomendações de IAM

Use os seguintes papéis predefinidos do IAM para facilitar cenários comuns:

Para uma lista dos papéis predefinidos do IAM, consulte Papéis predefinidos do GKE.

O GKE usa contas de serviço do IAM anexadas aos nós para executar tarefas do sistema, como geração de registros e monitoramento. No mínimo, essas contas de serviço de nó precisam ter o papel Conta de serviço de nó padrão do Kubernetes Engine (roles/container.defaultNodeServiceAccount) no seu projeto. Por padrão, o GKE usa a conta de serviço padrão do Compute Engine, que é criada automaticamente no seu projeto, como a conta de serviço do nó.

Interação do IAM com o Kubernetes RBAC

O IAM e o RBAC do Kubernetes trabalham juntos para ajudar a gerenciar o acesso ao cluster. O RBAC controla o acesso no nível do cluster e do namespace, enquanto o IAM funciona no nível do projeto. Uma entidade precisa ter permissões suficientes em qualquer nível para trabalhar com recursos no cluster.

A seguir