Gerenciar usuários do Distributed Cloud Connected

Esta página explica como gerenciar usuários em um cluster do Distributed Cloud connected.

Ao criar um cluster do Distributed Cloud connected, apenas a conta de usuário usada para criar o cluster recebe acesso a ele. Para conceder acesso a mais usuários ao cluster, faça uma destas ações:

Conceder as permissões necessárias usando o RBAC do Kubernetes

Esta seção descreve como conceder as permissões exigidas pelas necessidades comerciais de um usuário à conta dele usando o controle de acesso baseado em função (RBAC) do Kubernetes. Essas permissões são encapsuladas por vários papéis. Depois de conceder o papel apropriado a uma conta de usuário, adicione essa conta ao cluster conectado do Distributed Cloud de destino.

O Distributed Cloud connected não oferece suporte a grupos do Identity and Access Management ou provedores de identidade de terceiros para uso com o RBAC do Kubernetes em clusters do Distributed Cloud connected.

É necessário usar os seguintes recursos do Kubernetes para conceder papéis aos usuários:

  • ClusterRole: permite aplicar um conjunto de permissões a qualquer namespace no cluster e também concede acesso a recursos de todo o cluster.
  • ClusterRoleBinding: vincula um recurso ClusterRole a uma conta de usuário.
  • Role: permite aplicar um conjunto de permissões a um namespace específico.
  • RoleBinding: vincula um Role ou um ClusterRole recurso a uma conta de usuário em um namespace específico.

Conceder permissões para um administrador de cluster

Ao criar um cluster do Distributed Cloud connected, a conta de usuário usada para isso se torna automaticamente o administrador do cluster. Para conceder permissões de administrador de cluster a outros usuários, vincule a conta de usuário de destino ao papel cluster-admin criando um recurso ClusterRoleBinding e aplique-o ao cluster:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: BINDING_NAME
subjects:
  kind: User
  name: ACCOUNT_NAME
roleRef:
  kind: ClusterRole
  name: cluster-admin
  apiGroup: rbac.authorization.k8s.io

Substitua:

  • BINDING_NAME: um nome que identifica exclusivamente essa vinculação de papel.
  • ACCOUNT_NAME: o nome da conta de usuário de destino.

Também é possível usar o seguinte comando kubectl:

kubectl create clusterrolebinding "BINDING_NAME" \
  --clusterrole cluster-admin --user "ACCOUNT_NAME"

Substitua:

  • BINDING_NAME: um nome que identifica exclusivamente essa vinculação de papel.
  • ACCOUNT_NAME: o nome da conta de usuário de destino.

Conceder permissões para um desenvolvedor de aplicativos

Para conceder a um desenvolvedor de aplicativos as permissões necessárias para implantar cargas de trabalho no cluster de destino, faça o seguinte:

  1. Crie um recurso Role que conceda as permissões para criar e gerenciar pods, serviços e implantações no namespace de destino e aplique-o ao cluster:

    apiVersion: rbac.authorization.k8s.io/v1
 kind: Role
 metadata:
   namespace: NAMESPACE
   name: ROLE_NAME
 rules:
   apiGroups: ["apps", ""]
   resources: ["pods", "deployments", "services"]
   verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]

    Substitua:

    • NAMESPACE: o nome do namespace de destino.
    • ROLE_NAME: um nome que identifica exclusivamente esse papel.

  2. Crie um recurso RoleBinding que vincule as contas de usuário de destino ao papel criado na etapa anterior e aplique-o ao cluster:

    apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
 namespace: NAMESPACE
 name: BINDING_NAME
subjects:
 kind: User
 name: ACCOUNT_NAME
 kind: User
 name: ACCOUNT_NAME
roleRef:
 kind: Role
 name: ROLE_NAME
 apiGroup: rbac.authorization.k8s.io

    Substitua:

    • BINDING_NAME: um nome que identifica exclusivamente essa vinculação de papel.
    • NAMESPACE: o nome do namespace de destino.
    • ACCOUNT_NAME: o nome da conta de usuário de destino.
    • ROLE_NAME: o nome do papel de destino.

Conceder permissões para um agente de serviço do Cloud Build

Para conceder a um agente de serviço do Cloud Build as permissões necessárias para implantar cargas de trabalho no cluster de destino, faça o seguinte:

  1. Crie um recurso Role que conceda as permissões para criar e gerenciar pods, serviços e implantações no namespace de destino e aplique-o ao cluster:

    apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
 namespace: NAMESPACE
 name: ROLE_NAME
rules:
 apiGroups: ["apps", ""]
 resources: ["pods", "deployments", "services"]
 verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]

    Substitua:

    • NAMESPACE: o nome do namespace de destino.
    • ROLE_NAME: um nome que identifica exclusivamente esse papel.

  2. Crie um recurso RoleBinding que vincule a conta do agente de serviço do Cloud Build de destino ao papel criado na etapa anterior e aplique-o ao cluster:

    apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
 namespace: NAMESPACE
 name: BINDING_NAME
subjects:
 kind: User
 name: PROJECT_ID@cloudbuild.gserviceaccount.com
roleRef:
 kind: Role
 name: ROLE_NAME
 apiGroup: rbac.authorization.k8s.io

    Substitua:

    • BINDING_NAME: um nome que identifica exclusivamente essa vinculação de papel.
    • NAMESPACE: o nome do namespace de destino.
    • PROJECT_ID: o ID do projeto de destino. Google Cloud
    • ROLE_NAME: o nome do papel de destino.

Se você precisar conceder a um agente de serviço do Cloud Build permissões para implantar e gerenciar cargas de trabalho em todos os namespaces no cluster de destino, crie um ClusterRole e um ClusterRoleBinding recurso em vez dos recursos Role e RoleBinding.

Conceder permissões para visualizar informações do cluster

Para conceder as permissões necessárias para visualizar informações detalhadas sobre o cluster no Google Cloud console, faça o seguinte:

  1. Crie um recurso ClusterRole que permita que o agente do Connect represente o usuário que precisa visualizar as informações do cluster no Google Cloud console:

    apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
 name: ROLE_NAME
rules:
 apiGroups: [""]
 resources: ["users"]
 verbs: ["impersonate"]
 resourceNames: ["ACCOUNT_NAME"]

    Substitua:

    • ROLE_NAME: o nome do papel de destino.
    • ACCOUNT_NAME: o nome da conta de usuário de destino.

  2. Crie um recurso ClusterRoleBinding que vincule a conta do agente de serviço do Connect ao papel criado na etapa anterior e aplique-o ao cluster:

    apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
 name: BINDING_NAME
subjects:
 kind: ServiceAccount
 name: ACCOUNT_NAME
roleRef:
 kind: ClusterRole
 name: ROLE_NAME
 apiGroup: rbac.authorization.k8s.io

    Substitua:

    • BINDING_NAME: um nome que identifica exclusivamente essa vinculação de papel.
    • ACCOUNT_NAME: o nome da conta de usuário de serviço de destino.
    • ROLE_NAME: o nome do papel de destino.

É necessário criar um par de recursos ClusterRole e ClusterRoleBinding separado para cada usuário afetado.

Também é possível usar a ferramenta de linha de comando kubectl para conceder as permissões necessárias para visualizar informações do cluster da seguinte maneira:

  1. Crie um recurso ClusterRole que permita que o agente do Connect represente o usuário que precisa visualizar as informações do cluster no Google Cloud console:

    kubectl create clusterrole "ROLE_NAME" --verb impersonate \
 --resource users --resource-name "ACCOUNT_NAME"

    Substitua:

    • ROLE_NAME: o nome do papel de destino.
    • ACCOUNT_NAME: o nome da conta de usuário de serviço de destino.

  2. Crie um recurso ClusterRoleBinding que vincule a conta do agente de serviço do Connect ao papel criado na etapa anterior e aplique-o ao cluster:

    kubectl create clusterrolebinding "BINDING_NAME" --clusterrole \
 "ROLE_NAME" --serviceaccount "ACCOUNT_NAME"

    Substitua:

    • BINDING_NAME: um nome que identifica exclusivamente essa vinculação de papel.
    • ACCOUNT_NAME: o nome da conta de usuário de serviço de destino.
    • ROLE_NAME: o nome do papel de destino.

Usar o gateway do Connect para acessar clusters do Distributed Cloud connected

Você tem a opção de usar o gateway do Connect para acessar seus clusters do Distributed Cloud connected. Um usuário do gateway do Connect precisa de um ou mais dos seguintes papéis, dependendo dos requisitos comerciais:

  • Administrador do gateway do Connect (roles/gkehub.gatewayAdmin): concede acesso à API do gateway do Connect. Esse papel permite o uso da ferramenta de linha de comando kubectl para gerenciar o cluster.
  • Editor do gateway do Connect (roles/gkehub.gatewayEditor): concede acesso de leitura e gravação ao cluster.
  • Leitor do gateway do Connect (roles/gkehub.gatewayReader): concede acesso somente leitura ao cluster.
  • Visualizador do GKE Hub (roles/gkehub.viewer): concede a capacidade de recuperar arquivos kubeconfig do cluster.

Para mais informações sobre como usar o gateway do Connect, consulte o seguinte: