Autorização e controle de acesso

O Identity and Access Management (IAM) no Google Distributed Cloud (GDC) com isolamento físico permite controlar quem tem acesso a quais recursos e quais ações podem ser realizadas neles.

Entender como o IAM funciona no GDC ajuda a gerenciar o acesso de maneira eficaz, garantindo que os membros tenham as permissões necessárias para desempenhar seus papéis, mantendo a segurança do ambiente com isolamento físico.

Este documento é destinado a públicos-alvo dos grupos de administradores de plataforma e operadores de aplicativos (como administradores de TI, engenheiros de segurança ou desenvolvedores de aplicativos) que querem entender a autorização e o controle de acesso no GDC com isolamento físico. Este documento também ajuda os operadores de infraestrutura a criar uma compreensão básica dos conceitos de controle de acesso. Para mais informações, consulte Públicos-alvo da documentação do GDC com isolamento físico.

O modelo de controle de acesso

O GDC estrutura o acesso em torno de três componentes principais: membros (quem), papéis (o quê) e escopo do recurso (onde).

O modelo de controle de acesso

O controle de acesso consiste em duas etapas distintas: provar quem você é (autenticação) e determinar o que você pode fazer (autorização):

  • Autenticação:o GDC não armazena contas ou senhas de usuários. O GDC se conecta ao provedor de identidade (IdP) da sua organização para que você possa fazer login com suas credenciais corporativas.
  • Autorização:depois da autenticação, o IAM do GDC verifica os papéis atribuídos para determinar a quais recursos você pode acessar e quais ações pode realizar.

Membros

Um membro é uma identidade a quem você pode conceder acesso a recursos. O GDC agrupa os membros em duas categorias principais com base em onde eles são gerenciados: identidades humanas e não humanas.

Identidades humanas

As identidades humanas são os usuários e grupos que fazem login no GDC. Em vez de armazenar contas ou senhas de usuários, o GDC se conecta aos sistemas de login ou IdPs (como Active Directory, LDAP ou Okta) da sua organização usando protocolos de federação de identidade padrão, como OpenID Connect (OIDC) ou SAML 2.0.

Há dois tipos de identidades humanas:

  • Usuários:usuários humanos individuais que fazem login no sistema usando as credenciais corporativas.
  • Grupos:coleções de usuários humanos gerenciados no IdP da sua organização. Conceder um papel a um grupo o concede automaticamente a todos os membros desse grupo.

O GDC usa IdPs para identificar exclusivamente identidades humanas. Como seu ambiente pode se conectar a vários IdPs (por exemplo, se departamentos diferentes usam sistemas de login diferentes), o GDC distingue entre os IdPs para garantir que você conceda acesso à pessoa correta.

Ao gerenciar o acesso, o GDC adiciona automaticamente um prefixo de IdP exclusivo a todos os nomes de usuários e grupos externos:

  • Formato:idpprefix-username@domain.com (ou idpprefix-group-name para grupos).
  • Exemplo: se o IdP da sua organização estiver configurado com o prefixo agency-a, e você fizer login como alice@example.com, o IAM do GDC vai reconhecer você como agency-a-alice@example.com.

Identidades não humanas

As identidades não humanas são chamadas de identidades de serviço (ou contas de serviço). Você as cria e gerencia diretamente no GDC (como recursos ProjectServiceAccount) para permitir que aplicativos, scripts ou cargas de trabalho automatizadas interajam com APIs de maneira segura.

Como as contas de serviço são gerenciadas internamente pelo GDC, elas não usam prefixos de IdP. Em vez disso, elas são identificadas pelo projeto e nome (por exemplo, serviceAccount:projectName:serviceAccountName ao usar a CLI gdcloud).

Para mais informações, consulte Proteger chaves de conta de serviço.

Permissões e papéis

Uma permissão é a autoridade para realizar uma ação específica em um recurso (por exemplo, criar uma VM ou excluir um banco de dados). Você não concede permissões diretamente aos membros. Em vez disso, o GDC agrupa as permissões em papéis.

O GDC oferece dois tipos de papéis:

  • Papéis predefinidos:pacotes integrados de permissões criados e gerenciados pelo GDC. O GDC oferece uma biblioteca abrangente de papéis predefinidos adaptados a funções e serviços específicos (variando de papéis amplos, como o de visualizador de projetos, a papéis de serviço granulares, como o de administrador de projetos de buckets ou o de visualizador do KMS).
  • Papéis personalizados:pacotes de permissões definidos pelo usuário que podem ser criados quando os papéis predefinidos não atendem às necessidades da sua organização.

As permissões concedidas por papéis do IAM são puramente aditivas. Elas concedem acesso, mas não incluem regras de negação. Quando você concede vários papéis a um membro, ele recebe a união de todas as permissões nesses papéis. Para restringir ou negar o acesso a serviços específicos em toda a organização, você pode configurar políticas da organização.

Escopo do recurso

Você sempre concede acesso em um nível específico da hierarquia de recursos do GDC. O escopo determina a quais recursos o membro pode acessar. Em ambientes com várias zonas, os papéis atribuídos em qualquer escopo são aplicados automaticamente em todas as zonas por padrão.

É possível conceder papéis nos seguintes escopos de recursos:

  • Organização:o contêiner de nível superior do seu ambiente. Os papéis concedidos no nível da organização são aplicados em toda a organização, herdando automaticamente todos os projetos e recursos nela.
  • Projeto:um contêiner dentro da organização usado para agrupar recursos para equipes ou aplicativos específicos. Os projetos servem como limites de segurança estritos. Os papéis concedidos no nível do projeto são aplicados apenas a esse projeto específico e aos recursos dele (como máquinas virtuais, bancos de dados e clusters do Kubernetes).

Para mais informações, consulte Hierarquia de recursos e Controle de permissões para um universo de várias zonas.

Como o acesso é autorizado

O GDC gerencia e autoriza o acesso principalmente usando um modelo de controle de acesso baseado em função (RBAC, na sigla em inglês). Em um modelo RBAC, você não atribui permissões diretamente a usuários ou cargas de trabalho individuais. Em vez disso, você atribui papéis a membros em um escopo de recurso específico para determinar o acesso.

O GDC implementa o RBAC usando os seguintes recursos personalizados do Kubernetes:

  • IAMRole: define um pacote específico de permissões.
  • IAMRoleBinding: vincula um membro (um usuário humano, grupo ou conta de serviço) a um IAMRole em um escopo de organização ou projeto.

Para conceder acesso a recursos da organização ou do projeto, crie um IAMRoleBinding usando o console do GDC, a CLI gdcloud ou aplicando manifestos de recursos personalizados (arquivos YAML) usando a CLI kubectl.

Por exemplo, para permitir que um membro da equipe visualize máquinas virtuais em um projeto, crie um IAMRoleBinding no escopo desse projeto vinculando a identidade do membro a um papel de visualizador. Quando o membro tenta visualizar uma máquina virtual, o GDC verifica as vinculações de papéis ativas, confirma se o papel atribuído contém a permissão necessária e autoriza a solicitação.

Embora o console do GDC e a CLI gdcloud se conectem aos seus recursos automaticamente, o acesso direto à API usando a CLI kubectl exige a autenticação no cluster do Kubernetes ou no servidor da API específico que hospeda esse recurso gerando um arquivo kubeconfig. Para mais detalhes, consulte Fazer login e gerar um arquivo kubeconfig.

Para mais informações sobre como gerenciar vinculações de papéis, consulte Conceder e revogar acesso.

Como o IAM do GDC com isolamento físico difere de Google Cloud

Se você tiver experiência no gerenciamento de acesso em Google Cloud, o GDC usa conceitos semelhantes, mas os implementa de maneira diferente para operar em uma infraestrutura com isolamento físico baseada no Kubernetes.

A tabela a seguir compara o IAM no GDC com Google Cloud:

Recurso Descrição GDC com isolamento físico Google Cloud
Identidade do usuário (autenticação) Sistema de identidade usado para autenticar usuários humanos. Federado com seu IdP externo usando prefixos de IdP necessários (por exemplo, idpprefix-user@domain.com). Contas do Google (como o Gmail) ou identidades corporativas federadas pelo Cloud Identity ou pelo Google Workspace.
Mecanismo de autorização O sistema subjacente que avalia e aplica permissões. Principalmente o controle de acesso baseado em função (RBAC) do Kubernetes, em que as solicitações de acesso são avaliadas localmente pelo servidor da API em relação às vinculações de papéis. É possível usar políticas da organização para definir restrições de recursos. O serviço global do Cloud IAM do Google. Avalia as solicitações de API de maneira centralizada em relação às políticas de acesso anexadas em qualquer nível da hierarquia de recursos.
Vinculações de papéis Como os membros são mapeados para papéis em recursos específicos. Recursos personalizados IAMRoleBinding individuais. Cada vinculação é um objeto que vincula membros a um papel. As permissões de papéis do IAM são puramente aditivas (as regras de negação podem ser configuradas separadamente pelas políticas da organização). Uma única política de acesso do IAM anexada a cada recurso, pasta ou organização. Contém várias vinculações que mapeiam membros para papéis e oferece suporte a regras condicionais ou de negação.
Contas de serviço Identidades não humanas usadas por aplicativos e cargas de trabalho automatizadas. Contas de serviço locais criadas em um projeto específico (ProjectServiceAccount). As chaves públicas são armazenadas no cluster, enquanto as chaves privadas são gerenciadas e protegidas localmente pelo cliente. Identidades globais gerenciadas de maneira centralizada pelo Google. As credenciais podem ser gerenciadas automaticamente pelo Google ou baixadas como arquivos de chave para autenticação de qualquer lugar.
Hierarquia de recursos Estrutura de contêiner usada para organizar recursos e herdar permissões. Hierarquia de duas camadas: organização > projetos Hierarquia de várias camadas: organização > pastas > projetos
Escopo de permissão de várias zonas Como as permissões são avaliadas e propagadas em zonas de disponibilidade ou regiões. Usa o RBAC do Kubernetes gerenciado por um servidor da API global, que coordena e replica vinculações de papéis em servidores da API zonais para que o acesso seja aplicado em todas as zonas por padrão. Emprega um serviço global do IAM totalmente gerenciado. As permissões atribuídas em qualquer nível de recurso são inerentemente globais e aplicadas automaticamente em todas as regiões e zonas.
Ferramentas de cliente Interfaces principais, ferramentas de CLI e APIs usadas para gerenciar o acesso. Console do GDC, CLI gdcloud e APIs KRM. Google Cloud console, CLI gcloud e APIs REST ou gRPC.
Acesso direto à API Como as ferramentas e os scripts são autenticados para gerenciar recursos diretamente usando APIs. O acesso direto à API usando a CLI kubectl exige a autenticação no cluster do Kubernetes ou no servidor da API específico que hospeda esse recurso gerando um arquivo kubeconfig. (O console do GDC e a CLI gdcloud se conectam aos recursos automaticamente.) O acesso direto à API usando gcloud ou endpoints REST/gRPC usa credenciais centralizadas (gcloud auth login) que são aplicadas globalmente em todos os serviços sem a necessidade de logins específicos do cluster.

A seguir