Configurar o acesso do usuário para o GKE Identity Service

Este documento é destinado a administradores de cluster que já configuraram clusters para o GKE Identity Service seguindo as instruções em Configurar clusters para o GKE Identity Service no nível da frota ou Configurar clusters para o GKE Identity Service com OIDC. Ele informa como configurar (e restringir) o acesso ao cluster configurado para os desenvolvedores da sua organização e outros usuários do cluster.

Autenticar usando o acesso a arquivos

Depois de configurar um cluster, você precisa gerar um arquivo de configuração de login e distribuí-lo aos usuários do cluster. Esse arquivo permite que os usuários façam login no cluster na linha de comando com o provedor escolhido, conforme descrito em Acessar clusters com o GKE Identity Service.

Somente com provedores OIDC, os usuários também podem fazer login no cluster no console do Google Cloud sem um arquivo de login, conforme descrito em Trabalhar com clusters do console do Google Cloud.

Gerar a configuração de login

Console

(Apenas no nível da frota)

Copie o comando gcloud exibido e execute-o para gerar o arquivo.

gcloud

Se você configurou o cluster usando a CLI gcloud ou se precisa gerar o arquivo novamente, execute o seguinte comando para gerar o arquivo:

gcloud anthos create-login-config --kubeconfig=KUBECONFIG

em que KUBECONFIG é o caminho do arquivo kubeconfig do cluster. Se houver vários contextos no kubeconfig, o contexto atual será usado. Talvez seja necessário redefinir o contexto atual para o cluster correto antes de executar o comando.

Veja detalhes de referência completos para esse comando, incluindo parâmetros opcionais adicionais, no Guia de referência da Google Cloud CLI.

O nome padrão do arquivo de configuração de login é kubectl-anthos-config.yaml, que é o nome que a Google Cloud CLI espera ao usar o arquivo para fazer login. Se você quiser alterar esse nome para um nome não padrão, consulte a seção relevante em Distribuir a configuração de login.

Para resolver problemas de acesso do usuário, consulte Resolver problemas de acesso do usuário.

Distribuir a configuração de login

Veja a seguir algumas abordagens possíveis para distribuir o arquivo de configuração:

• Hospedar o arquivo em um URL acessível. Os usuários podem especificar esse local com a sinalização --login-config ao executar gcloud anthos auth login, permitindo que a Google Cloud CLI receba o arquivo.

  Considere hospedar o arquivo em um host seguro. Consulte a sinalização --login-config-cert da CLI gcloud para ver mais informações sobre o uso de certificados PEM para acesso HTTPS seguro.

• Forneça manualmente o arquivo para cada usuário, com informações sobre onde salvá-lo na máquina local. A Google Cloud CLI espera encontrar o arquivo em um local padrão específico do SO. Se o arquivo tiver um nome ou local não padrão, seus usuários precisarão usar a sinalização --login-config para especificar o local do arquivo de configuração ao executar comandos no cluster. As instruções para os usuários salvarem o arquivo estão em Acessar clusters com o GKE Identity Service.

• Usar suas ferramentas internas para enviar o arquivo de configuração de autenticação para a máquina de cada usuário. A Google Cloud CLI espera encontrar o arquivo nos seguintes locais, dependendo do sistema operacional do usuário:

  Linux

  $HOME/.config/google/anthos/kubectl-anthos-config.yaml

  macOS

  $HOME/Library/Preferences/google/anthos/kubectl-anthos-config.yaml

  Windows

  %APPDATA%\google\anthos\kubectl-anthos-config.yaml

Autenticar usando o acesso FQDN (recomendado)

Em vez de distribuir o arquivo de configuração para todos os usuários, é possível configurar um acesso de login de usuário usando o acesso FQDN. Os usuários podem se autenticar diretamente no servidor do serviço de identidade do GKE com um nome de domínio totalmente qualificado (FQDN). Para provedores SAML, o acesso de login do usuário só é permitido por esse processo alternativo de autenticação.

Observação: essa abordagem de autenticação tem suporte para o GKE on VMware e GKE em Bare Metal da versão 1.29. Você precisa fazer upgrade para a versão gcloud da CLI, a 474.0.0.

Compartilhar FQDN com usuários

Em vez de um arquivo de configuração, os administradores de cluster podem compartilhar o FQDN do servidor de identidade do GKE com os usuários. Os usuários podem usar esse FQDN para fazer login no cluster. O formato do URL para login é APISERVER-URL, em que o URL contém o FQDN do servidor de cluster.

Um exemplo de formato de APISERVER-URL é https://cluster.company.com.

Acesso de login do usuário com certificados SNI confiáveis

Os certificados SNI simplificam o acesso ao cluster aproveitando os certificados confiáveis já presentes em dispositivos corporativos. Os administradores usam esse certificado no momento da criação do cluster. Como usuário, você precisa usar o FQDN fornecido pelo administrador para fazer login no cluster. Se preferir, use um arquivo kubeconfig seguro em que o token seja armazenado após a autenticação.

Antes de executar o comando a seguir, verifique se o certificado usado pelo servidor do serviço de identidade do GKE é confiável para o dispositivo em que a atividade de login do usuário é realizada.

gcloud anthos auth login --server APISERVER-URL --kubeconfig OUTPUT_FILE

Substitua:

• APISERVER-URL: FQDN do servidor do serviço de identidade do GKE.
• OUTPUT_FILE: use essa sinalização se o arquivo kubeconfig estiver em um local diferente do padrão. Se essa sinalização for omitida, os tokens de autenticação serão adicionados ao arquivo kubeconfig no local padrão. Por exemplo: --kubeconfig /path/to/custom.kubeconfig.

Acesso de login do usuário usando certificados emitidos pela CA do cluster

Como usuário, se você não usar um certificado SNI confiável no nível do cluster, o certificado usado pelo serviço de identidade será emitido pela autoridade de certificação (CA) do cluster. Os administradores distribuem esse certificado de CA para os usuários. Execute o seguinte comando usando o certificado de CA do cluster para fazer login no cluster:

gcloud anthos auth login --server APISERVER-URL --kubeconfig OUTPUT_FILE --login-config-cert CLUSTER_CA_CERTIFICATE

Observação: como recomendação, os usuários podem confiar no certificado de CA nos dispositivos e navegadores deles seguindo as instruções específicas do dispositivo. Esta atividade só deve ser feita uma vez. Quando o certificado de CA for confiável, será possível fazer login no cluster sem especificar o argumento --login-config-cert no comando.

Configurar opções do serviço de identidade

Com essa abordagem de autenticação, você tem a opção de configurar a duração do ciclo de vida do token. Na resposta automática do ClientConfig, uma nova seção IdentityServiceOptions é introduzida com um novo parâmetro sessionDuration. Isso permite que os usuários configurem o ciclo de vida do token (em minutos). O parâmetro sessionDuration tem um limite inferior de 15 minutos e um limite máximo de 1.440 minutos (24 horas).

Veja um exemplo da resposta automática do ClientConfig:

spec:
    IdentityServiceOptions:
      sessionDuration: INT

em que INT é a duração da sessão em minutos.

Configurar o controle de acesso baseado em papéis (RBAC, na sigla em inglês)

A autenticação costuma ser combinada com o controle de acesso baseado em papéis (RBAC, na sigla em inglês) do Kubernetes para fornecer um controle de acesso mais refinado aos clusters para usuários autenticados e contas de serviço. Sempre que possível, é recomendável criar políticas do RBAC que usem nomes de grupos em vez de identificadores de usuários. Ao vincular suas políticas de RBAC explicitamente a grupos, você pode gerenciar totalmente os privilégios de acesso do usuário com seu provedor de identidade, para que o cluster não precise ser atualizado sempre que os privilégios do usuário forem alterados. Observe que, para configurar o controle de acesso com base na associação a grupos de segurança com OIDC, verifique se o GKE Identity Service está configurado para aceitar informações de associação a grupos do provedor de identidade.

Por exemplo, se você quiser que determinados usuários autenticados tenham acesso aos pods do cluster, crie um ClusterRole que conceda acesso a esses recursos, como no exemplo a seguir:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: pod-reader
rules:
- apiGroups: [""]
  # The resource type for which access is granted
  resources: ["pods"]
  # The permissions granted by the ClusterRole
  verbs: ["get", "watch", "list"]

Em seguida, crie um ClusterRoleBinding correspondente para conceder as permissões no ClusterRole aos usuários relevantes. Nesse caso, os membros do grupo de segurança us-east1-cluster-admins e o usuário com o ID u98523-4509823:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: read-pods-admins
subjects:
  # Grants anyone in the "us-east1-cluster-admins" group
  # read access to Pods in any namespace within this cluster.
- kind: Group
  name: gid-us-east1-cluster-admins # Name is case-sensitive
  apiGroup: rbac.authorization.k8s.io
  # Grants this specific user read access to Pods in any
  # namespace within this cluster
- kind: User
  name: uid-u98523-4509823
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

Observação: se seu provedor de identidade retornar um nome de grupo que contenha caracteres duplos de barra invertida, um dos caracteres de barra invertida deverá ser omitido quando você referenciar o nome do grupo no recurso ClusterRoleBinding. Por exemplo, se você tiver criado um grupo chamado corp\\my-group, faça referência a ele no recurso ClusterRoleBinding como corp\my-group, porque o primeiro caractere de barra invertida é tratado como um caractere de escape.

No exemplo abaixo, essa ClusterRoleBinding concede permissões em ClusterRole ao grupo relevante com o ID 12345678-BBBb-cCCCC-0000-123456789012. Essa configuração é relevante apenas para provedores do Azure AD e está disponível para clusters do Google Distributed Cloud Virtual para Bare Metal.

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: pod-reader-binding
subjects:
  # Retrieves group information for the group ID mentioned
- kind: Group
  name: 12345678-BBBb-cCCCC-0000-123456789012
  apiGroup: rbac.authorization.k8s.io

Para mais informações sobre o uso do RBAC, consulte Configurar o controle de acesso baseado em função e Como usar a autorização do RBAC.

Criar um papel do RBAC para acesso ao console do Google Cloud

Os usuários autenticados com provedores OIDC podem fazer login em clusters no console do Google Cloud e na linha de comando.

Os usuários autenticados que querem acessar os recursos de um cluster no Console do Google Cloud precisam ter as permissões relevantes do Kubernetes para fazer isso. Se você não quiser conceder a esses usuários permissões mais abrangentes, como as de um administrador de cluster, crie um papel personalizado de RBAC que inclua as permissões mínimas para visualizar os nós, volumes permanentes, pods e classes de armazenamento do cluster. Para definir esse conjunto de permissões, crie um recurso de RBAC ClusterRole, cloud-console-reader, no cluster.

cloud-console-reader concede aos usuários as permissões get, list e watch nos nós, volumes permanentes, pods e classes de armazenamento do cluster, o que permite que eles vejam detalhes sobre esses recursos.

kubectl

Para criar o ClusterRole do cloud-console-reader e aplicá-lo ao cluster, execute o seguinte comando:

cat <<EOF > cloud-console-reader.yaml
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: cloud-console-reader
rules:
- apiGroups: [""]
  resources: ["nodes", "persistentvolumes", "pods"]
  verbs: ["get", "list", "watch"]
- apiGroups: ["storage.k8s.io"]
  resources: ["storageclasses"]
  verbs: ["get", "list", "watch"]
EOF
kubectl apply -f cloud-console-reader.yaml

É possível conceder esse ClusterRole aos usuários ao configurar suas políticas de permissão, conforme descrito na seção anterior. Os usuários também precisam de permissões do IAM para visualizar clusters no console do Google Cloud.