Configurar papéis de autorização

Visualização

Este produto ou recurso está sujeito aos "Termos das ofertas pré-GA" na seção "Termos de Serviço gerais" dos Termos específicos do serviço. Os produtos e recursos pré-GA estão disponíveis "no estado em que se encontram" e podem ter suporte limitado. Para mais informações, consulte as descrições da fase de lançamento.

Papéis de autorização

O modo particular do Anthos é enviado com quatro papéis de autorização predefinidos:

Nome do papel	Nome do Kubernetes ClusterRole (no cluster de administração)	Permissões
Operador de infraestrutura	Administrador de clusters	Acesso completo de leitura/gravação a todos os recursos.
Operador de infraestrutura (somente leitura)	visualização	Acesso somente leitura à maioria das coisas no Centro de gerenciamento, exceto papéis, vinculações de papéis e segredos. No momento, os usuários terão acesso de gravação ao Grafana para editar os painéis.
Administrador da plataforma	Administrador da plataforma de Anthos	Acesso de leitura/gravação a clusters de usuários, gerenciamento de recursos do Anthos, Anthos Identity Service e Anthos Config Management. Acesso de leitura e exclusão para máquinas. Acesso somente leitura ao serviço Bootstrap.
Administrador da plataforma (Somente leitura)	Administrador da plataforma de Anthos (somente leitura)	Acesso somente leitura a tudo que um administrador da plataforma pode ver. No momento, os usuários terão acesso de gravação ao Grafana para editar os painéis.

Qualquer pessoa com acesso a ADMIN_KUBECONFIG é autenticada como membro no grupo system:master do Kubernetes, o que permite qualquer ação ao servidor da API Kubernetes. Por exemplo, eles podem listar todos os secrets executando o:

kubectl get secrets --all-namespaces --kubeconfig=${ADMIN_KUBECONFIG}

O acesso usando ADMIN_KUBECONFIG é autenticado como um nome de usuário genérico admin, e isso dificulta o rastreamento da pessoa que executa o comando. Consequentemente, é importante manter ADMIN_KUBECONFIG em um local seguro e usá-lo somente quando necessário (por exemplo, ao configurar vinculações de papel do operador da plataforma inicial ou ao recuperar falhas do OIDC).

IMPORTANTE: verifique se usuários e grupos não têm o prefixo system:. O prefixo system: é reservado para o sistema do Kubernetes.

Acesso a métricas e console da Web

O modo particular do Anthos sincroniza automaticamente todos os usuários vinculados a esses quatro papéis na lista de permissões do centro de gerenciamento e do acesso às métricas (Grafana).

Os papéis com direitos de acesso somente leitura são negados ao tentar executar uma ação de gravação no Centro de Gerenciamento.

Vinculações de papéis

Ao configurar o OIDC no console da Web, é possível definir um usuário inicial vinculado ao papel de administrador de plataforma. Com um kubeconfig conectado para o usuário administrador da plataforma inicial, há duas abordagens para vincular outro usuário ao papel Administrador da plataforma:

Abordagem I: (recomendado) configure a GroupMembership no provedor OIDC e crie vinculações de papéis com base no grupo

Essa abordagem vincula um dos seus grupos a um papel predefinido para conceder a todos os membros do grupo os mesmos direitos de acesso do papel predefinido.

Antes de começar, verifique o seguinte:

• Determine o provedor OIDC do grupo.
• O campo "Declaração de grupos" na guia "Perfil do OIDC" precisa ser igual ao nome da declaração em que há informações de associação a grupos no lado do provedor OIDC. O modo particular do Anthos fornece um valor padrão: groups, mas se o provedor OIDC tiver um diferente, verifique se você o definiu na guia "Perfil do OIDC".
• Anote o "Prefixo do grupo" na guia "Perfil do OIDC". É necessário incluir o prefixo do grupo antes de todos os nomes de grupo. Por exemplo, se você tiver gid- como o prefixo do grupo e um grupo "admin-group" no provedor OIDC, use gid-admin-group. Observe que o separador - é a parte do prefixo do grupo e o sistema não adiciona nenhum separador para você.

Use a guia de gerenciamento de acesso na IU do centro de gerenciamento para gerenciar suas vinculações de papel com base em grupos.

Não é possível adicionar ou atualizar uma vinculação a um papel com mais privilégios do que os da conta usada atualmente para fazer login. Por exemplo, se você tiver feito login como administrador da plataforma, não poderá vincular um grupo a um papel de operador de infraestrutura.

Como alternativa, execute o seguinte comando para criar uma vinculação de papel com base no grupo. O valor passado para group= precisa ser o mesmo que o nome do grupo no provedor OIDC prefixado com o prefixo do grupo:

kubectl create clusterrolebinding anthos-platform-admin-group-binding \
--kubeconfig=${ADMIN_OIDC_KUBECONFIG} --clusterrole=anthos-platform-admin \
--group=gid-anthos-platform-admin-group

Agora, qualquer usuário que você adicionou a anthos-platform-admin-group no provedor OIDC tem todas as permissões como administrador da plataforma

Da mesma forma, você pode usar o seguinte comando para vincular um grupo ao papel de administrador de plataforma (somente leitura):

kubectl create clusterrolebinding anthos-platform-admin-read-only-group-binding \
  --kubeconfig=${ADMIN_OIDC_KUBECONFIG} --clusterrole=anthos-platform-admin-read-only \
  --group=gid-anthos-platform-admin-read-only-group

Para evitar o escalonamento de privilégios, um administrador de plataforma não pode vincular um grupo a um papel de "Operador de infraestrutura" ou de "Operador de infraestrutura (somente leitura)". Para inicializar o primeiro grupo de operadores de infraestrutura, você precisa de ADMIN-KUBECONFIG:

kubectl create clusterrolebinding anthos-platform-operator-group-binding \
  --kubeconfig=${ADMIN_KUBECONFIG} --clusterrole=cluster-admin --group=gid-anthos-platform-operator-group

Depois disso, é possível usar um KUBECONFIG com uma conta de operador de infraestrutura conectada para vincular outros grupos a quaisquer papéis:

# Bind a group to Infrastructure Operator (Read Only):
kubectl create clusterrolebinding anthos-platform-operator-read-only-binding \
  --clusterrole=view --group=gid-anthos-platform-operator-read-only-group --kubeconfig=${ADMIN_OIDC_KUBECONFIG}

Abordagem II: criar vinculações de função com base no usuário

Também é possível criar vinculações de papel com base no papel do usuário. Os comandos para criar vinculações de papel são semelhantes ao uso de "Group". É necessário substituir --group por --user.

Você também precisa anexar o prefixo de usuário do seu perfil OIDC a todos os nomes de usuário. Por exemplo, se o provedor OIDC estiver definido para ter um prefixo de usuário uid- e você quiser vincular [e-mail] a um papel, use [e-mail].

Também é possível usar a guia de gerenciamento de acesso para gerenciar vinculações de papéis aos usuários.

Veja abaixo um exemplo de comando para criar uma vinculação de papel para [e-mail] e conceder a ele permissões de administrador da plataforma:

kubectl create clusterrolebinding charlie-platform-admin-binding \
  --clusterrole=anthos-platform-admin --user=[e-mail] --kubeconfig=${ADMIN_OIDC_KUBECONFIG}

Para excluir uma vinculação de papel e remover os direitos de acesso de um usuário, atualize as vinculações existentes em vez de excluí-las. Por exemplo, revogue o direito de administrador da plataforma de [e-mail]:

kubectl patch clusterrolebinding charlie-platform-admin-binding \
  -p '{"subjects":[]}' --kubeconfig=${ADMIN_OIDC_KUBECONFIG}

Também é possível solicitar que o operador da infraestrutura exclua o ClusterRoleBinding.

PRÁTICA RECOMENDADA: o Kubernetes não impede que um usuário com menos direitos de acesso exclua as vinculações de usuários com mais direitos de acesso. Portanto, o administrador da plataforma não recebe direito de excluir a ClusterRoleBinding. É preferível usar grupos no seu provedor OIDC para gerenciar usuários, porque você pode excluir um usuário do grupo correspondente.

Observações

• Há mais informações sobre o controle de acesso baseado em papéis (RBAC, na sigla em inglês) na documentação oficial (em inglês).
• Nenhum papel de autorização predefinido foi definido nos clusters do usuário. O acesso ao servidor da API Kubernetes em cada acesso ao cluster de usuários é aberto para qualquer um que tenha o kubeconfig.
• Os administradores da plataforma não têm permissão para excluir uma vinculação de papel para impedir que eles excluam vinculações de usuários com privilégios maiores. Para revogar o acesso de um usuário, atualize a vinculação de papel que o vincula a uma lista de assunto vazia. A ação de exclusão na IU de gerenciamento de acesso também atualiza as vinculações de papéis para uma lista de assuntos vazia, em vez de excluir as vinculações pelo mesmo motivo.
• O nome do ClusterRoleBinding precisa ser exclusivo. Somente o mais recente aplicado/criado terá efeito quando houver várias vinculações de papel do cluster com o mesmo nome.

Direitos de acesso a recursos do Kubernetes para cada papel predefinido

Nesta seção, fornecemos detalhes sobre todos os direitos de acesso a recursos do Kubernetes para cada papel predefinido.

Operador de infraestrutura

O operador de infraestrutura corresponde ao papel cluster-admin integrado do Kubernetes, que pode executar quaisquer verbos em quaisquer recursos.

Operador de infraestrutura (somente leitura)

O operador de infraestrutura (somente leitura) corresponde ao papel de view k8s integrado, que pode ler todos os recursos, exceto Role, ClusterRole, RoleBinding, ClusterRoleBinding e Secret.

Muitas informações úteis, como o kubeconfig do cluster de usuário, são armazenadas como Secrets, por isso, o operador de infraestrutura (somente leitura) não é totalmente funcional.

Administrador da plataforma

O administrador da plataforma pode ter os seguintes direitos de acesso:

Recurso	Verbos
namespaces	get, list, watch, create, update
pods	get, list, watch
serviços	get, list, watch
events	get, list, watch
configmaps	get, list, watch
deployments	get, list, watch
daemonsets	get, list, watch
replicasets	get, list, watch
statefulsets	get, list, watch
jobs	get, list, watch
cronjobs	get, list, watch
memberships.managementcenter.anthos.cloud.google.com	get, list, watch, create, update, delete
onpremuserclusters.managementcenter.anthos.cloud.google.com	get, list, watch, create, update, delete
clusters.baremetal.cluster.gke.io	get, list, watch, create
nodepools.baremetal.cluster.gke.io	get, list, watch, create
clusters.cluster.x-k8s.io	get, list, watch
machines.baremetal.cluster.gke.io	get, list, watch
inventorymachines.baremetal.cluster.gke.io	get, list, watch
addresspools.managementcenter.anthos.cloud.google.com	get, list, watch
bootstrapservicebindings.managementcenter.anthos.cloud.google.com	get, list, watch, create, update, delete
bootstrapservices.managementcenter.anthos.cloud.google.com	get, list, watch
bootstrapservicebindingitems.managementcenter.anthos.cloud.google.com	get, list, watch
adminoperators.managementcenter.anthos.cloud.google.com	get, list, watch
clientconfigs.authentication.gke.io	get, list, watch, create, update, delete
configmanagementbindings.managementcenter.anthos.cloud.google.com	get, list, watch, create, update, delete
configmanagementfeaturespecs.managementcenter.anthos.cloud.google.com	get, list, watch, create, update, delete
configmanagementbindingitems.managementcenter.anthos.cloud.google.com	get, list, watch, create, update, delete
servicemeshbindings.managementcenter.anthos.cloud.google.com	get, list, watch, create, update, delete
servicemeshfeaturespecs.managementcenter.anthos.cloud.google.com	get, list, watch, create, update, delete
servicemeshbindingitems.managementcenter.anthos.cloud.google.com	get, list, watch, create, update, delete
identityservicebindings.managementcenter.anthos.cloud.google.com	get, list, watch, create, update, delete
identityservicefeaturespecs.managementcenter.anthos.cloud.google.com	get, list, watch, create, update, delete
identityservicebindingitems.managementcenter.anthos.cloud.google.com	get, list, watch, create, update, delete
updatablecomponents.managementcenter.anthos.cloud.google.com	get, list, watch
domainidpmappings.managementcenter.anthos.cloud.google.com	get, list, watch, create, update, delete
domainidpmappings.managementcenter.anthos.cloud.google.com	get, list, watch, create, update, delete
logmons.addons.gke.io	get, list, watch, create, update, delete
clusterrolebindings.rbac.authorization.k8s.io	get, list, watch, create, update

O administrador de plataforma também tem acesso de leitura a secrets para permitir que eles consigam um kubeconfig autenticado como um papel cluster-admin em um cluster de usuário.

O administrador de plataforma também pode ler e gravar secrets e configmaps com um rótulo logmon no kube-system para configurar o Logmon.

Administrador da plataforma (somente leitura)

O administrador de plataforma (somente leitura) tem os mesmos direitos de acesso que o administrador de plataforma, exceto:

• Todos os verbos relacionados a gravação (criar, atualizar e excluir) não são concedidos.
• Para acessar um cluster de usuário, o administrador de plataforma (somente leitura) pode ler um kubeconfig que seja autenticado como um papel view no cluster de usuário.