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
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 executargcloud 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.
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 arquivokubeconfig
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
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
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.