O Google usa tecnologia de IA na tradução de conteúdos para seu idioma de preferência. As traduções com IA podem ter erros.

Gerenciar o acesso a clusters Standard

Standard

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.

Este documento é destinado 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

Antes de gerenciar o acesso a clusters Standard, você precisa ter as permissões necessárias e preparar o ambiente.

Solicitar papéis do IAM

Entre em contato com o administrador do IAM da organização para solicitar os seguintes papéis com base nas tarefas que você precisa realizar:

Administrador do IAM do projeto (project-iam-admin): cria, atualiza e exclui vinculações de papéis para clusters Standard em um projeto.
Administrador do cluster Standard (standard-cluster-admin): cria, atualiza e exclui vinculações de papéis em um cluster Standard específico.

Preparar o ambiente

Faça o download e instale a CLI gdcloud, se ainda não tiver feito isso.
Instale a CLI kubectl.

Conceder permissões de acesso para clusters Standard

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

Faça login com o provedor de identidade configurado usando a CLI gdcloud.
Conceda ao usuário o papel de administrador do cluster Standard (standard-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 standard-cluster-admin).
- USER_ACCOUNT: a conta de usuário para a qual você quer conceder o papel, 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 Standard 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=standard-cluster-admin \
  --member=user:fop-user@example.com
```

Gerenciar o acesso no cluster Standard

Um usuário com o papel de administrador do cluster Standard (standard-cluster-admin) pode conceder acesso em um cluster Standard:

Faça login com o provedor de identidade configurado usando a CLI gdcloud.
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 clusters 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.
Defina permissões no cluster Standard usando kubectl.

Os usuários com permissões standard-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.

Observação: os usuários só podem conceder permissões que já possuem. Eles não podem usar esse acesso para aumentar as próprias permissões.

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 uma ServiceAccount chamada 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
```