Configurar papéis de autorização

Esta página é destinada a operadores de infraestrutura.

Nesta página, descrevemos os papéis de autorização, as vinculações de papéis e os direitos de acesso a recursos para o Anthos em execução no modo desconectado.

Papéis de autorização

O Anthos em execução no modo desconectado tem quatro papéis de autorização predefinidos:

Nome da função Nome do ClusterRole no Kubernetes (no cluster de administração) Permissões
Operador de infraestrutura anthos-infrastructure-operator Acesso completo de leitura/gravação a todos os recursos.
Operador de infraestrutura (somente leitura) anthos-infrastructure-operator-read-only Acesso somente leitura à maioria dos itens no Centro de gerenciamento do Anthos, ClusterRole/Role, vinculações ClusterRole/Role, definições de recursos personalizados e acesso limitado de leitura a secrets.

Os usuários têm acesso de gravação ao Grafana para editar 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 de inicialização e às definições de recursos personalizados.
Administrador da plataforma (somente leitura) Administrador da plataforma de Anthos (somente leitura) Acesso para ler a tudo que um administrador da plataforma pode ver.

Os usuários têm acesso de gravação ao Grafana para editar 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}

${ADMIN_KUBECONFIG} é o caminho do arquivo kubeconfig do cluster de administrador.

O acesso usando ADMIN_KUBECONFIG é autenticado como o nome de usuário genérico admin, o que 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).

Acesso ao Centro de gerenciamento e às métricas

O Anthos em execução no modo desconectado sincroniza automaticamente todos os usuários vinculados a esses quatro papéis na lista de permissões do acesso ao Centro de gerenciamento e à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 do Centro de gerenciamento, é possível definir um usuário inicial vinculado ao papel de administrador da plataforma. Com um kubeconfig conectado para o usuário administrador da plataforma inicial, há duas abordagens para vincular outro usuário ao papel de administrador da plataforma:

Recomendado: configure a assinatura de grupo no provedor OIDC e criar 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

Antes de começar, verifique o seguinte:

  • Determine o provedor OIDC do grupo.
  • O campo Reivindicação de grupos na guia Perfil OIDC deve ser igual ao nome da declaração que contém informações de associação a grupos no lado do provedor OIDC. O Anthos executado no modo desconectado fornece a este campo o valor padrão de groups. No entanto, se o provedor OIDC tiver um valor diferente, configure-o na guia Perfil OIDC.
  • Anote o Prefixo do grupo na guia OIDC perfil. É 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ê.

Gerenciar vinculações usando o console do Centro de gerenciamento

Use a guia Acesso no console do Centro de gerenciamento para gerenciar suas vinculações de papéis com base nos grupos. Aplicar perfil de identidade durante a criação do cluster

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.

Gerenciar vinculações usando kubectl

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

Qualquer usuário que você adicionou a anthos-platform-admin-group no provedor OIDC agora tem todas as permissões de 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=anthos-infrastructure-operator --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=anthos-infrastructure-operator-read-only --group=gid-anthos-platform-operator-read-only-group --kubeconfig=${ADMIN_OIDC_KUBECONFIG}

Criar vinculações de papéis 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". Substitua --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 joedoe@example.com a um papel, use uid-joedoe@example.com.

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

Veja um comando de amostra para criar uma vinculação de papel para charlie@example.com e conceder a ela permissões de administrador de plataforma:

kubectl create clusterrolebinding charlie-platform-admin-binding \
  --clusterrole=anthos-platform-admin --user=uid-charlie@example.com --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 charlie@example.com:

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.

Observações

  • Veja mais informações sobre autorização em Como usar a autorização RBAC.
  • Nenhum papel de autorização predefinido está definido nos clusters de 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 página Identidade e acesso do console do Centro de gerenciamento também atualiza as vinculações de papel para uma lista de assunto vazia, em vez de excluir as vinculações pelo mesmo motivo.
  • O nome do recurso ClusterRoleBinding precisa ser exclusivo. Somente a vinculação mais recente aplicada ou criada entra em vigor quando há 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 papel do operador de infraestrutura corresponde ao papel anthos-infrastructure-operator do Kubernetes, que pode executar qualquer verbo em qualquer recurso.

Operador de infraestrutura (somente leitura)

O papel de operador de infraestrutura (somente leitura) corresponde ao papel de anthos-infrastructure-operator-read-only do Kubernetes, que pode ler todos os recursos nos ApiGroups listados aqui com acesso de leitura limitado a Secret. O acesso de leitura para Secret é limitado apenas ao token de acesso do cluster de administrador, ao kubeconfig do cluster de usuário e aos secrets com um rótulo logmon no kube-system para geração de registros e monitoramento.

ApiGroups Recurso Verbos
"" configmaps get, list, watch
"" endpoint get, list, watch
"" persistentvolumeclaims get, list, watch
"" persistentvolumeclaims/status get, list, watch
"" pods get, list, watch
"" replicationcontrollers get, list, watch
"" replicationcontrollers/scale get, list, watch
"" serviceaccounts get, list, watch
"" serviços get, list, watch
"" services/status get, list, watch
"" vinculações get, list, watch
"" events get, list, watch
"" limitranges get, list, watch
"" namespaces/status get, list, watch
"" pods/log get, list, watch
"" pods/status get, list, watch
"" replicationcontrollers/status get, list, watch
"" resourcequotas get, list, watch
"" resourcequotas/status get, list, watch
"" namespaces get, list, watch
apiextensions.k8s.io customresourcedefinitions get, list, watch
apps * get, list, watch
escalonamento automático * get, list, watch
batch * get, list, watch
cert-manager.io * get, list, watch
extensions * get, list, watch
metrics.k8s.io * get, list, watch
networking.k8s.io * get, list, watch
policy * get, list, watch
rbac.authorization.k8s.io * get, list, watch
addons.gke.io * get, list, watch
authentication.gke.io * get, list, watch
baremetal.cluster.gke.io * get, list, watch
cluster.x-k8s.io * get, list, watch
managementcenter.anthos.cloud.google.com * get, list, watch

Administrador da plataforma

O papel de administrador da plataforma tem 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
domainconfigs.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
customresourcedefinitions.apiextensions.k8s.io get, list, watch

Os administradores da plataforma têm acesso de leitura a secrets para permitir que eles tenham um kubeconfig autenticado como um papel cluster-admin em um cluster de usuário.

Os administradores da plataforma podem ler e gravar secrets e configmaps com um rótulo logmon no kube-system para configurar o Logmon.

Administrador da plataforma (somente leitura)

O papel de administrador da plataforma (somente leitura) tem os mesmos direitos de acesso que um administrador da 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.

A seguir