Gerenciar o acesso a clusters padrão

Neste documento, explicamos como gerenciar permissões para clusters Standard no Google Distributed Cloud (GDC) com isolamento físico usando a CLI gdcloud. Os clusters Standard são ambientes do Kubernetes configuráveis e com escopo de projeto que têm serviços padrão mínimos e oferecem mais flexibilidade e controle para cargas de trabalho personalizadas.

Para mais informações sobre clusters Standard e outros tipos de clusters, consulte Configurações de cluster do Kubernetes.

Esta página é destinada a públicos-alvo do grupo de operadores de aplicativos, como operações de desenvolvedores ou cientistas de dados, que precisam gerenciar e proteger recursos em projetos do GDC. Para mais informações, consulte Públicos-alvo da documentação do GDC com isolamento físico.

Antes de começar

  • Peça ao administrador do IAM da organização para conceder a você o papel de administrador do IAM do projeto (project-iam-admin). Para mais informações sobre papéis, consulte Definições de papéis.
  • Instale a CLI gdcloud se ainda não tiver feito isso.

Conceder permissões de acesso para clusters Standard

Um usuário com o papel de administrador do IAM do projeto (project-iam-admin) executa as etapas a seguir para conceder a outros usuários os papéis necessários para gerenciar o acesso em clusters Standard:

  1. Faça login com o provedor de identidade configurado usando a CLI gdcloud.

  2. Conceda ao usuário o papel de administrador do cluster (cluster-admin) para o projeto. Esse comando vincula o usuário à função, permitindo que ele gerencie o acesso no cluster Standard.

    Consulte Descrições de papéis predefinidos e Definições de papéis para projetos para mais informações sobre os papéis.

    gdcloud projects add-iam-policy-binding PROJECT \
  --role=ROLE \
  --member=user:USER_ACCOUNT

    Substitua as seguintes variáveis:

    • PROJECT: o nome do projeto em que o cluster Standard existe.
    • ROLE: o nome do papel que você quer conceder (como cluster-admin ou cluster-developer).
    • USER_ACCOUNT: a conta de usuário a que você quer conceder a função, incluindo o prefixo do provedor de identidade associado à sua organização (como idpprefix-user@example.com). O prefixo específico usado depende da configuração do IdP da sua organização. Consulte Conectar a um provedor de identidade para mais informações.

    O exemplo a seguir concede o papel de administrador do cluster a user@example.com, supondo que o prefixo do provedor de identidade seja fop- para o projeto foo:

    gdcloud projects add-iam-policy-binding foo \
  --role=cluster-admin \
  --member=user:fop-user@example.com

Gerenciar o acesso no cluster Standard

Um usuário que recebeu a função cluster-admin na seção anterior realiza as seguintes etapas:

  1. Faça login com o provedor de identidade configurado usando a CLI gdcloud.

  2. Gere um arquivo kubeconfig para um cluster Standard usando a flag --standard. Essa flag é obrigatória para segmentar um cluster Standard.

    export KUBECONFIG=KUBECONFIG_FILE
gdcloud get-credentials STANDARD_CLUSTER_NAME --standard --project=PROJECT

    Substitua as seguintes variáveis:

    • KUBECONFIG_FILE: o caminho para o arquivo kubeconfig, como standard-cluster-kubeconfig.yaml.
    • STANDARD_CLUSTER_NAME: o nome do cluster Standard.
    • PROJECT: o nome do projeto em que o cluster Standard existe.

  3. Defina permissões no cluster Standard usando kubectl.

    Os usuários com permissões cluster-admin podem criar objetos Role e ClusterRole personalizados. Para conceder essas permissões, eles podem criar os objetos Rolebinding e ClusterRoleBinding correspondentes para vincular os papéis a assuntos específicos, como usuários ou contas de serviço.

    O exemplo a seguir usa kubectl para criar um Role personalizado de amostra chamado test-role no namespace test:

    kubectl apply -f - <<EOF
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: test-role
  namespace: test
rules:
- apiGroups:
  - ""
  resources:
  - configmaps
  verbs:
  - get
EOF

    O exemplo a seguir cria o RoleBinding para o Role chamado test-role no namespace test. Ele concede permissões ao usuário alice@example.com com o prefixo do provedor de identidade fop-, bem como a um ServiceAccount chamado my-service-account no namespace default:

    kubectl apply -f - <<EOF
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: test-role-binding
  namespace: test
subjects:
- kind: User
  name: fop-alice@example.com
  apiGroup: rbac.authorization.k8s.io
- kind: ServiceAccount
  name: my-service-account
  namespace: default
roleRef:
  kind: Role
  name: test-role
  apiGroup: rbac.authorization.k8s.io
EOF