Autorização e controle de acesso

O Identity and Access Management (IAM) no appliance isolado do Google Distributed Cloud (GDC) 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 isolado.

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 de usuário nem senhas. O GDC pode aproveitar o provedor de identidade (IdP) Keycloak agrupado ou se conectar ao IdP da sua organização para que você possa fazer login com suas credenciais.
  • 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 que você pode conceder acesso a recursos. O GDC agrupa os membros em duas categorias principais com base em onde você os gerencia: 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 de usuário ou senhas, o GDC pode aproveitar o IdP Keycloak agrupado ou se conectar aos sistemas de login atuais da sua organização (como Active Directory, LDAP ou Okta), 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.
  • Grupos:coleções de usuários humanos gerenciados no Keycloak ou 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 o 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ário 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 conta de serviço 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 atuais 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.

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.

É 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 de 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).

Como o acesso é autorizado

O GDC gerencia e autoriza o acesso principalmente usando um modelo de controle de acesso baseado em papéis (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 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 isolada baseada no Kubernetes.

A tabela a seguir compara o IAM no GDC e 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 ou gerenciado com o IdP Keycloak agrupado, 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 papéis (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. 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. 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 dentro de 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 centralmente pelo Google. As credenciais podem ser gerenciadas automaticamente pelo Google ou baixadas como arquivos de chaves para autenticar de qualquer lugar.
Hierarquia de recursos Estrutura de contêiner usada para organizar recursos e herdar permissões. Hierarquia de dois níveis: organização > projetos Hierarquia de vários níveis: organização > pastas > projetos
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