Conceder e revogar acesso

Cada sujeito (um usuário ou um grupo) segue um processo de duas etapas para ter acesso ao servidor da API Management e ao cluster do Kubernetes:

  • Acesso ao servidor da API Management:conceda a um assunto com permissões no servidor da API Management usando ClusterRoleBinding ou RoleBinding a um ClusterRole predefinido.

  • Acesso ao cluster do Kubernetes:conceda acesso específico ao namespace ou em todo o cluster.

    • Para acesso específico do namespace:para conceder acesso ao namespace de um projeto específico no cluster, crie um ProjectRole e um ProjectRoleBinding correspondente. Esse processo propaga um Role e um RoleBinding do Kubernetes para um Namespace do Kubernetes no cluster, que corresponde ao Project associado ao ProjectRole e ao ProjectRoleBinding.

    • Para acesso em todo o cluster:para conceder acesso a todos os namespaces no cluster, crie um OrganizationRole e um OrganizationRoleBinding correspondente. Esse processo propaga um ClusterRole e um ClusterRoleBinding do Kubernetes para todo o cluster do Kubernetes.

As personas (IO, PA, AO) não são papéis, mas sim coleções de papéis de usuário mapeados para permissões específicas e atribuídos a usuários individuais.

O administrador do IAM da organização e o administrador do IAM do projeto podem criar mais papéis e vinculações de papéis do projeto para conceder outras permissões específicas do projeto. No entanto, os administradores do IAM da organização podem criar papéis e vinculações de papéis para qualquer projeto. Por outro lado, os administradores do IAM do projeto só podem criar papéis e vinculações de papéis para projetos a que têm permissão de acesso.

Configurar vinculações de papéis

É possível configurar vinculações de função que dão aos membros da equipe acesso a recursos no nível da organização ou do projeto.

Para receber as permissões necessárias para configurar vinculações de papéis, peça ao administrador do IAM da organização para conceder a você o papel de administrador do IAM da organização.

Para atribuir uma função a um membro autorizado, siga estas etapas:

Console

  1. Faça login no console do GDC.
  2. Clique em Selecionar projeto para escolher uma organização ou um projeto.
    • Para configurar vinculações de função em uma organização, selecione uma organização.
    • Para configurar vinculações de função em um projeto, selecione um projeto.
  3. No menu de navegação, clique em Identidade e acesso > Acesso.
  4. Clique em Adicionar membro.
  5. Na lista Provedor de identidade, selecione uma opção.
  6. Escolha se quer adicionar usuários individuais ou grupos.
  7. No campo Nome de usuário ou alias do grupo, insira o nome de usuário, o endereço de e-mail ou o alias.
  8. Na lista Papel, selecione o papel que você quer atribuir ao usuário ou grupo, como Visualizador da organização no nível da organização ou Criador de projetos no nível do projeto.
  9. Clique em Adicionar.

O membro aparece na lista Membro autorizado.

gdcloud

  1. Verifique se você instalou a CLI gdcloud.

  2. Faça login usando o comando gdcloud auth login para autenticar com seu provedor de identidade. Para mais informações, consulte a autenticação da CLI gdcloud.

  3. Configure as vinculações de função.

    • Configurar vinculações de papéis para uma organização:

      gdcloud organizations add-iam-policy-binding root \
        --member=USER_ACCOUNT \
        --role=ROLE_TYPE/ROLE
      

      Substitua as seguintes variáveis:

      • USER_ACCOUNT: a conta de usuário a que você quer conceder o papel. Essa flag aceita um endereço de e-mail do usuário com o prefixo do provedor de identidade (user:idpprefix-user@example.com) ou um nome de conta de serviço com o projeto da conta de serviço (serviceAccount:projectName:serviceAccountName).
      • ROLE_TYPE: o ClusterRole, Role ou OrganizationRole para o qual você está configurando a vinculação de papel.
      • ROLE: o nome da função predefinida ou personalizada que você quer atribuir ao usuário (como project-creator).
    • Configure vinculações de papéis para um projeto:

      gdcloud projects add-iam-policy-binding PROJECT \
        --member=USER_ACCOUNT \
        --role=ROLE_TYPE/ROLE
      

      Substitua as seguintes variáveis:

      • PROJECT: o nome do projeto para o qual você está configurando a vinculação de função.
      • USER_ACCOUNT: a conta de usuário a que você quer conceder o papel. Essa flag aceita um endereço de e-mail do usuário com o prefixo do provedor de identidade (user:idpprefix-user@example.com) ou um nome de conta de serviço com o projeto da conta de serviço (serviceAccount:projectName:serviceAccountName).
      • ROLE_TYPE: o Role ou ProjectRole para que você está configurando a vinculação de papel.
      • ROLE: o nome da função predefinida ou personalizada que você quer atribuir ao usuário (como project-viewer).

API

  1. Exporte a credencial de usuário que você usa:

    export YOUR_IAM_ADMIN_KUBECONFIG=YOUR_IAM_ADMIN_KUBECONFIG
    
  2. Exporte a conta de usuário a que você quer atribuir a função, incluindo o prefixo do provedor de identidade (como idpprefix-paul@example.com):

    export USERNAME=IDP_PREFIX-USER_EMAIL
    
  3. Exporte o nome da função que o usuário precisa, como project-creator. Consulte Definições de papéis para mais detalhes sobre a função.

    export ROLE_NAME=ROLE_NAME
    
  4. Atribua um usuário a um ClusterRole, Role, ProjectRole ou OrganizationRole:

    • Atribua um usuário a um ClusterRole:

      kubectl create --kubeconfig ${YOUR_IAM_ADMIN_KUBECONFIG} \
      clusterrolebinding ${USERNAME}-${ROLE_NAME}-binding \
      --clusterrole=${ROLE_NAME} --user=${USERNAME}
      

      Para casos em que um ClusterRole exige um RoleBinding em vez de um ClusterRoleBinding, consulte as Definições de papéis para descobrir qual tipo de vinculação o papel precisa e crie um RoleBinding no namespace gpc-system:

      kubectl create --kubeconfig ${YOUR_IAM_ADMIN_KUBECONFIG} \
      rolebinding ${USERNAME}-${ROLE_NAME}-binding \
      --clusterrole=${ROLE_NAME} --user=${USERNAME} --namespace=gpc-system
      
    • Atribua um usuário a um Role:

      1. Exporte o namespace em que a vinculação precisa ser criada:

        export BINDING_NAMESPACE=BINDING_NAMESPACE
        
      2. Execute os comandos a seguir para criar um RoleBinding:

        kubectl create --kubeconfig ${YOUR_IAM_ADMIN_KUBECONFIG} \
        rolebinding ${USERNAME}-${ROLE_NAME}-binding \
        --role=${ROLE_NAME} --user=${USERNAME} --namespace=${BINDING_NAMESPACE}
        
    • Atribua um usuário a um ProjectRole:

      1. Crie um arquivo projectrolebinding.yaml:

        apiVersion: resourcemanager.gdc.goog/v1
        kind: ProjectRoleBinding
        metadata:
          name: BINDING_NAME
          namespace: PROJECT_NAME
        spec:
          roleRef:
            apiGroup: resourcemanager.gdc.goog
            kind: ProjectRole
            name: ROLE_NAME
          subjects:
          - apiGroup: rbac.authorization.k8s.io
            kind: USER_KIND
            name: USERNAME
        

        Substitua:

        • BINDING_NAME: um nome para a vinculação que o usuário pode personalizar (como user-project-creator-binding).
        • PROJECT_NAME: o nome do projeto a que você está concedendo a função.
        • ROLE_NAME: o nome do ProjectRole que você está atribuindo ao usuário.
        • USER_KIND: o tipo de usuário, que pode ser User, Group ou ServiceAccount.
        • USERNAME: o endereço de e-mail do usuário para quem você está atribuindo o papel, incluindo o prefixo do provedor de identidade (como idpprefix-paul@example.com). Isso precisa corresponder ao USERNAME exportado.
      2. Aplique o arquivo projectrolebinding.yaml:

        kubectl create -f projectrolebinding.yaml
        
    • Atribua um usuário a um OrganizationRole:

      1. Crie um arquivo organizationrolebinding.yaml:

        apiVersion: resourcemanager.gdc.goog/v1
        kind: OrganizationRoleBinding
        metadata:
          name: BINDING_NAME
          namespace: gpc-system
        spec:
          roleRef:
            apiGroup: resourcemanager.gdc.goog
            kind: OrganizationRole
            name: ROLE_NAME
          subjects:
          - apiGroup: rbac.authorization.k8s.io
            kind: USER_KIND
            name: USERNAME
        

        Substitua:

        • BINDING_NAME: um nome para a vinculação que o usuário pode personalizar (como user-organization-creator-binding).
        • ROLE_NAME: o nome do OrganizationRole que você está atribuindo ao usuário.
        • USER_KIND: o tipo de usuário, que pode ser User, Group ou ServiceAccount.
        • USERNAME: o endereço de e-mail do usuário para quem você está atribuindo o papel, incluindo o prefixo do provedor de identidade (como idpprefix-paul@example.com). Isso precisa corresponder ao USERNAME exportado.
      2. Aplique o arquivo YAML organizationrolebinding.yaml:

        kubectl create -f organizationrolebinding.yaml
        

Remover vinculações de papéis

Quando o acesso não for mais necessário, remova um membro e os papéis, as permissões e o acesso associados a ele.

Para remover participantes, siga estas etapas:

Console

  1. Faça login no console do GDC.
  2. No menu de navegação, clique em Identidade e acesso > Acesso.
  3. Na lista Membros autorizados, selecione um membro.
  4. Clique em Remover membro.
  5. Quando solicitado, clique em Remover participante para confirmar.

gdcloud

  1. Verifique se você instalou a CLI gdcloud.

  2. Faça login usando o comando gdcloud auth login para autenticar com seu provedor de identidade. Para mais informações, consulte a autenticação da CLI gdcloud.

  3. Remova as vinculações de papéis.

    • Remover vinculações de papéis de uma organização:

      gdcloud organizations remove-iam-policy-binding root \
        --member=USER_ACCOUNT \
        --role=ROLE_TYPE/ROLE
      

      Substitua as seguintes variáveis:

      • USER_ACCOUNT: a conta de usuário de que você quer remover o papel. Essa flag aceita um endereço de e-mail do usuário com o prefixo do provedor de identidade (user:idpprefix-user@example.com) ou um nome de conta de serviço com o projeto da conta de serviço (serviceAccount:projectName:serviceAccountName).
      • ROLE_TYPE: o ClusterRole, Role ou OrganizationRole de que você está removendo a vinculação de papel.
      • ROLE: o nome da função predefinida ou personalizada que você quer remover da conta de usuário (como project-creator).
    • Remova as vinculações de papel de um projeto:

      gdcloud projects remove-iam-policy-binding PROJECT \
        --member=USER_ACCOUNT \
        --role=ROLE_TYPE/ROLE
      

      Substitua as seguintes variáveis:

      • PROJECT: o nome do projeto de que você está removendo a vinculação de função.
      • USER_ACCOUNT: a conta de usuário de que você quer remover o papel. Essa flag aceita um endereço de e-mail do usuário com o prefixo do provedor de identidade (user:idpprefix-user@example.com) ou um nome de conta de serviço com o projeto da conta de serviço (serviceAccount:projectName:serviceAccountName).
      • ROLE_TYPE: o Role ou ProjectRole para que você está removendo a vinculação de papel.
      • ROLE: o nome da função predefinida ou personalizada que você quer remover da conta de usuário (como project-viewer).

API

  1. Exporte a credencial de usuário que você usa:

    export YOUR_IAM_ADMIN_KUBECONFIG=YOUR_IAM_ADMIN_KUBECONFIG
    
  2. Exporte a conta de usuário de que você quer remover o papel, incluindo o prefixo do provedor de identidade (como idpprefix-paul@example.com):

    export USERNAME=IDP_PREFIX-USER_EMAIL
    
  3. Exporte o namespace em que a vinculação está sendo removida:

    export BINDING_NAMESPACE=BINDING_NAMESPACE
    
  4. Exclua o ClusterRoleBinding, RoleBinding, ProjectRoleBinding ou OrganizationRoleBinding para revogar a permissão concedida à conta de usuário:

    • Remova o ClusterRoleBinding de uma conta de usuário:

      kubectl --kubeconfig ${YOUR_IAM_ADMIN_KUBECONFIG} \
      delete clusterrolebinding ${USERNAME}-pa
      
    • Remova o RoleBinding de uma conta de usuário:

      kubectl --kubeconfig ${YOUR_IAM_ADMIN_KUBECONFIG} \
      delete rolebinding ${USERNAME}-pa \
      --namespace=${BINDING_NAMESPACE}
      
    • Remova o ProjectRoleBinding de uma conta de usuário:

      kubectl --kubeconfig ${YOUR_IAM_ADMIN_KUBECONFIG} \
      delete projectrolebinding ${USERNAME}-pa \
      --namespace=${BINDING_NAMESPACE}
      
    • Remova o OrganizationRoleBinding de uma conta de usuário:

      kubectl --kubeconfig ${YOUR_IAM_ADMIN_KUBECONFIG} \
      delete organizationrolebinding ${USERNAME}-pa \
      --namespace=gpc-system
      

Revogar o acesso do usuário

Se um membro sair da sua organização ou equipe, você poderá revogar o acesso dele ao appliance isolado do Google Distributed Cloud (GDC). Revogar o acesso de um usuário faz com que ele saia do dispositivo isolado do GDC e remove os papéis e permissões dele. Você também pode listar a atividade e as sessões do usuário com base no horário de início e término.

Para revogar o acesso de um usuário, faça o seguinte:

  1. Receba as permissões necessárias para revogar usuários. Peça ao administrador do IAM da organização para conceder a você o papel de administrador da sessão da organização (org-session-admin).

  2. Revogue o acesso do usuário:

    gdcloud admin auth revoke --accounts USER_EMAIL
    

    Substitua USER_EMAIL pelo e-mail do usuário para revogar o acesso.

    Depois de executar o comando, você vai ver uma saída semelhante a esta: Este exemplo revoga o acesso do usuário ariel@example.com:

    Success: NUMBER of sessions revoked for user ariel@example.com
    

    Neste exemplo, a variável NUMBER se refere ao número de sessões ativas do usuário.

  3. Confirme se você revogou o acesso do usuário executando o comando gdcloud admin auth revoke novamente. Se a operação for bem-sucedida, você verá o seguinte:

    No sessions found for account: ariel@example.com
    

Listar todos os usuários revogados

Para conferir todos os usuários revogados e a atividade e as sessões deles, faça o seguinte:

  • Liste todos os usuários revogados do horário de início e término:

    gdcloud admin auth list --format="csv(ACCOUNT, IDENTITY_PROVIDER, CREATION_TIME, EXPIRATION_TIME)"
    

    Se for bem-sucedido, você vai ver uma saída semelhante a esta:

    account,identity_provider,creation_time,expiration_time
    ariel@example.com,example-idp,2023-02-15 22:10:52,2023-02-15 23:10:52