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.

Faça a gestão do acesso a clusters padrão

Padrão

Este documento explica como gerir as autorizações para clusters padrão no Google Distributed Cloud (GDC) air-gapped através da CLI gdcloud. Os clusters padrão são ambientes Kubernetes configuráveis com âmbito do projeto e serviços predefinidos mínimos que oferecem maior flexibilidade e controlo para cargas de trabalho personalizadas.

Para mais informações sobre clusters padrão e outros tipos de clusters, consulte o artigo Configurações de clusters Kubernetes.

Este documento destina-se a públicos-alvo no grupo de operadores de aplicações, como operações de programadores ou cientistas de dados, que precisam de gerir e proteger recursos em projetos do GDC. Para mais informações, consulte o artigo Públicos-alvo para a documentação do GDC air-gapped.

Antes de começar

Antes de gerir o acesso a clusters padrão, tem de ter as autorizações necessárias e preparar o seu ambiente.

Peça funções de IAM

Contacte o administrador de IAM da organização para pedir as seguintes funções com base nas tarefas que tem de realizar:

Administrador de IAM do projeto (project-iam-admin): crie, atualize e elimine associações de funções para clusters padrão num projeto.
Administrador de clusters padrão (standard-cluster-admin): crie, atualize e elimine associações de funções num cluster padrão específico.

Prepare o seu ambiente

Transfira e instale a CLI gdcloud, se ainda não o tiver feito.
Instale a CLI kubectl.

Conceda autorizações para o acesso a clusters padrão

Um utilizador com a função de administrador de IAM do projeto (project-iam-admin) pode conceder a outros utilizadores as funções necessárias para gerir o acesso em clusters padrão:

Inicie sessão com o seu fornecedor de identidade configurado através da CLI gdcloud.
Conceda ao utilizador a função de administrador de clusters padrão (standard-cluster-admin) para o projeto. Este comando associa o utilizador à função, o que lhe permite gerir o acesso no cluster padrão.

Consulte os artigos Descrições de funções predefinidas e Definições de funções para projetos para mais informações sobre as funções.
```
gdcloud projects add-iam-policy-binding PROJECT \
  --role=ROLE \
  --member=user:USER_ACCOUNT
```
Substitua as seguintes variáveis:
- PROJECT: o nome do projeto onde o cluster padrão existe.
- ROLE: o nome da função que quer conceder (como standard-cluster-admin).
- USER_ACCOUNT: a conta de utilizador para a qual quer conceder a função, incluindo o prefixo do fornecedor 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 o artigo Ligue-se a um fornecedor de identidade para mais informações.
O exemplo seguinte concede a função de administrador de clusters padrão a user@example.com, partindo do princípio de que o prefixo do fornecedor de identidade é fop- para o projeto foo:
```
gdcloud projects add-iam-policy-binding foo \
  --role=standard-cluster-admin \
  --member=user:fop-user@example.com
```

Faça a gestão do acesso no cluster padrão

Um utilizador com a função de administrador de clusters padrão (standard-cluster-admin) pode conceder acesso num cluster padrão:

Inicie sessão com o seu fornecedor de identidade configurado através da CLI gdcloud.
Gere um ficheiro kubeconfig para um cluster padrão através da opção --standard. Esta opção é necessária para segmentar um cluster padrão.
```
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 ficheiro kubeconfig, como standard-cluster-kubeconfig.yaml.
- STANDARD_CLUSTER_NAME: o nome do cluster padrão.
- PROJECT: o nome do projeto onde o cluster padrão existe.
Defina as autorizações no cluster padrão através do comando kubectl.

Os utilizadores com autorizações standard-cluster-admin podem criar objetos Role e ClusterRole personalizados. Para conceder estas autorizações, podem criar os objetos Rolebinding e ClusterRoleBinding correspondentes para associar as funções a determinados assuntos, como utilizadores ou contas de serviço.

Nota: os utilizadores só podem conceder autorizações que já tenham. Não podem usar este acesso para aumentar as suas próprias autorizações.

O exemplo seguinte usa kubectl para criar uma Role personalizada de amostra denominada test-role no espaço de nomes 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 seguinte cria o RoleBinding para o Role denominado test-role no espaço de nomes test. Concede autorizações ao utilizador alice@example.com com o prefixo do fornecedor de identidade fop-, bem como a uma ServiceAccount denominada my-service-account no espaço de nomes 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
```