Configure clusters para o serviço de identidade do GKE com SAML

Este documento destina-se a administradores de clusters ou operadores de aplicações que pretendam configurar o GKE Identity Service em clusters individuais, permitindo que os programadores e outros utilizadores iniciem sessão nos clusters através dos respetivos detalhes de identidade existentes de um fornecedor de Security Assertion Markup Language (SAML). Este guia pressupõe que leu a vista geral do GKE Identity Service. As instruções neste documento partem do princípio de que o GKE Identity Service já foi registado no seu fornecedor de identidade como uma aplicação cliente.

Antes de começar

  • Certifique-se de que o administrador da plataforma lhe deu todas as informações necessárias do artigo Registe o serviço de identidade do GKE junto do seu fornecedor antes de iniciar a configuração.
  • Certifique-se de que tem as seguintes ferramentas de linha de comandos instaladas:

    • Use a versão 466.0.0 da CLI Google Cloud ou superior, que inclui o gcloud, a ferramenta de linha de comandos para interagir com o Google Cloud. Se precisar de instalar a CLI do Google Cloud, consulte o guia de instalação.
    • kubectl para executar comandos em clusters do Kubernetes. Se precisar de instalar o kubectl, siga estas instruções.

    Se estiver a usar o Cloud Shell como ambiente de shell para interagir com o Google Cloud, estas ferramentas são instaladas automaticamente.

  • Certifique-se de que inicializou a CLI gcloud para utilização com o projeto onde os clusters estão registados.

Configure o cluster

O serviço de identidade do GKE usa um tipo de recurso personalizado (CRD) especial do Kubernetes para configurar os seus clusters denominado ClientConfig, com campos para informações sobre o fornecedor de identidade e os parâmetros de que precisa para devolver informações do utilizador.

kubectl

Para editar o ClientConfig predefinido, certifique-se de que consegue estabelecer ligação ao cluster com kubectl e execute o seguinte comando:

kubectl --kubeconfig=KUBECONFIG_PATH edit ClientConfigs default -n kube-public

Substitua KUBECONFIG_PATH pelo caminho para o ficheiro kubeconfig do cluster, por exemplo, $HOME/.kube/config.

Um editor de texto carrega o recurso ClientConfig do seu cluster. Adicione o saml objeto conforme indicado no fragmento.

apiVersion: authentication.gke.io/v2alpha1
kind: ClientConfig
metadata:
  name: default
  namespace: kube-public
spec:
  authentication:
  - name: NAME
   saml:
     idpEntityID: ENTITY_ID
     idpSingleSignOnURI: SIGN_ON_URI
     idpCertificateDataList: IDP_CA_CERT
     userAttribute: USER_ATTRIBUTE
     groupsAttribute: {'<var name="user attribute">GROUPS_ATTRIBUTE</var>'}}
     userPrefix: USER_PREFIX
     groupPrefix: GROUP_PREFIX
     attributeMapping:
       ATTRIBUTE_KEY_1 : ATTRIBUTE_CEL_EXPRESSION_1
       ATTRIBUTE_KEY_2 : ATTRIBUTE_CEL_EXPRESSION_2
  certificateAuthorityData: CERTIFICATE_STRING
  preferredAuthentication: PREFERRED_AUTHENTICATION
  server: <>

# Rest of the resource is managed by Google. DO NOT MODIFY.
...

Pode configurar vários fornecedores de identidade no seu ClientConfig de acordo com os seus requisitos. Isto simplifica a gestão e oferece flexibilidade, permitindo-lhe configurar vários métodos de autenticação num recurso de configuração unificado. O exemplo seguinte ClientConfig define vários fornecedores de identidade na ordem necessária de precedência da autenticação.

apiVersion: v1
items:
- apiVersion: authentication.gke.io/v2alpha1
  kind: ClientConfig
...
  spec:
    authentication:
    - aws:
        region: us-west-2
      name: AWS Login
    - ldap:
    ...
    - saml:
      ...
    - azureAD:
      ...
    - oidc:
      name: Okta OIDC
      ...
    -oidc:
      name: Google OIDC
      ...

A tabela seguinte descreve os campos do objeto ClientConfig saml. Os campos que tem de adicionar dependem do seu fornecedor de identidade e das opções de configuração escolhidas pelo administrador da plataforma ao configurar o fornecedor para o GKE Identity Service.

Campo Obrigatória Descrição Formato
nome Sim O nome que quer usar para identificar esta configuração, normalmente o nome do fornecedor de identidade. Um nome de configuração tem de começar por uma letra, seguida de até 39 letras minúsculas, números ou hífenes, e não pode terminar com um hífen. String
idpEntityID Sim O ID da entidade SAML para o fornecedor SAML, especificado num formato URI. Por exemplo: https://www.idp.com/saml. String de URL
idpSingleSignOnURI sim O ponto final do SSO do fornecedor SAML, especificado num formato de URI. Por exemplo: https://www.idp.com/saml/sso. String de URL
idpCertificateDataList Sim Corresponde aos certificados do fornecedor de identidade usados para validar a resposta SAML. Estes certificados têm de estar codificados em Base64 padrão e no formato PEM. Só é suportado um máximo de dois certificados para facilitar a rotação de certificados do fornecedor de identidade. String
userAttribute Não Nome do atributo na resposta SAML que contém o nome de utilizador. String
groupsAttribute Não Nome do atributo na resposta SAML que contém as informações do grupo do utilizador. String
userPrefix Não O prefixo que quer antepor às reivindicações do utilizador para evitar conflitos com nomes existentes, se não quiser usar o prefixo predefinido. String
groupPrefix Não O prefixo que quer antepor aos nomes dos grupos de segurança. Isto destina-se a evitar conflitos com nomes existentes nas suas regras de controlo de acesso se tiver configurações para vários fornecedores de identidade (normalmente, o nome do fornecedor). String
attributeMapping Não O mapeamento de atributos de utilizador adicionais. String
certificateAuthorityData Não Se fornecido pelo administrador da plataforma, trata-se de uma string de certificado com codificação PEM para o fornecedor de identidade. Inclua a string resultante em certificateAuthorityData como uma única linha. String
preferredAuthentication Não Nome do método de autenticação preferido configurado no cluster. String

Depois de concluir o ClientConfig, guarde o ficheiro, o que atualiza o ClientConfig no cluster. Se tiver cometido erros de sintaxe, é solicitado que volte a editar a configuração para os corrigir.

O que se segue?

Depois de aplicar a configuração, continue a configurar o acesso dos utilizadores aos clusters.