Como configurar a autenticação do usuário do Cloud Service Mesh

A autenticação do usuário do Cloud Service Mesh é uma solução integrada para autenticação e controle de acesso do usuário final baseada em navegador para as cargas de trabalho implantadas. Ela permite a integração com provedores de identidade (IDP, na sigla em inglês) existentes para autenticação de usuários, assim como usa APIs do Istio e políticas de autorização para o gerenciamento de acesso. É uma alternativa fácil de usar se comparada à autenticação do JSON Web Token (JWT) do Istio.

Um caso de uso típico é quando uma organização usa o Cloud Service Mesh para hospedar um aplicativo da Web para a equipe de trabalho acessar usando um navegador da Web. Além disso, a organização precisa usar o provedor de identidade existente para gerenciar identidades de usuário. A autenticação de usuário do Cloud Service Mesh facilita a autenticação dos usuários com um fluxo de login e consentimento padrão do OpenID Connect (OIDC) baseado na Web. Quando o usuário é autenticado, o Cloud Service Mesh aplica políticas de autorização do Istio e, quando a autorização acontece, ele transmite a identidade para as cargas de trabalho em um formato de credencial seguro.

Como funciona

A autenticação do usuário do Cloud Service Mesh introduz um novo componente, authservice. Este componente integra-se ao Ingress baseado em Envoy como um serviço de autorização externo que intercepta todas as solicitações recebidas para autenticação. authservice implementa o lado do cliente do protocolo OIDC e permite o acesso de usuários a aplicativos por um navegador, em que os usuários concluem um fluxo de autenticação e consentimento interativo para estabelecer uma sessão de curta duração. authservice implementa protocolos padrão do setor para se integrar a qualquer provedor de identidade que possa atuar como um servidor de autorização OIDC. Quando o usuário é autenticado, as informações principais são encapsuladas em um RCToken no formato JWT, assinado por authservice, que o encaminha para a camada de autorização do Istio no ingresso. Este modelo fornece controle de acesso de perímetro para o tráfego na malha. Se o usuário estiver autorizado a acessar um recurso, esse RCToken também será encaminhado aos microsserviços para conseguir informações principais e para aplicar o controle de acesso detalhado.

O diagrama a seguir mostra o local de authservice na malha e como ele se relaciona com as outras partes da malha, como a entrada, as cargas de trabalho, o navegador do usuário e qualquer IDP existente.

Autenticação de usuário final

Os administradores podem instalar o authservice como um complemento em uma instalação do Cloud Service Mesh. Quando instalado, authservice lê a configuração do endpoint do OIDC e outras configurações associadas definidas no recurso personalizado UserAuth. O administrador pode usar as APIs ExternalAuthorization do Cloud Service Mesh para configurar o auth_server como um filtro na entrada.

Instalar o serviço de autenticação do usuário

As etapas a seguir explicam como configurar o authservice.

Pré-requisitos

Siga as etapas em Instalar ferramentas dependentes e validar o cluster para:
  • Se você estiver usando o Cloud Service Mesh gerenciado em um cluster particular, verifique se o cluster é capaz de enviar tráfego de saída para o IDP.

Certifique-se de que você atende aos pré-requisitos usando as etapas a seguir.

Personalizar a sobreposição de autenticação do usuário de instalação

Para instalar o serviço de autenticação do usuário, personalize a instalação do Cloud Service Mesh para adicionar um provedor de autorização externo no nível da malha. As etapas necessárias dependem se você está usando o Cloud Service Mesh gerenciado ou no cluster.

Gerenciado

  1. Atualize o ConfigMap para incluir o MeshConfig da autenticação do usuário. No comando a seguir, use o mesmo REVISION_LABEL usado ao provisionar o Cloud Service Mesh gerenciado, como asm-managed, asm-managed-rapid ou asm-managed-stable):

    kubectl edit configmap istio-REVISION_LABEL -n istio-system

  2. Adicione o seguinte texto ao campo mesh no MeshConfig:

    mesh: |-
...
  extensionProviders:
  - name: "asm-userauth-grpc"
    envoyExtAuthzGrpc:
      service: "authservice.asm-user-auth.svc.cluster.local"
      port: "10003"

  3. Criar e rotular o namespace asm-user-auth.

    kubectl create namespace asm-user-auth
kubectl label namespace asm-user-auth istio.io/rev=REVISION --overwrite

    Para encontrar o rótulo REVISION, consulte Rótulos de injeção.

  4. Instale o gateway do Istio no namespace asm-user-auth.

    kubectl apply -n asm-user-auth -f DIR_PATH/samples/gateways/istio-ingressgateway

No cluster

  1. Confira o exemplo de sobreposição de autenticação do usuário e atualize-o se houver personalizações na malha. É uma prática recomendada para manter esse arquivo de sobreposição no controle de origem.

    curl https://raw.githubusercontent.com/GoogleCloudPlatform/asm-user-auth/v1.2.1/overlay/user-auth-overlay.yaml > user-auth-overlay.yaml

  2. Siga o instalar o Cloud Service Mesh com sobreposição para usar um script fornecido pelo Google para instalar o Cloud Service Mesh com a sobreposição de autenticação do usuário. Exemplo:

    ./asmcli install \
  --project_id PROJECT_ID \
  --cluster_name CLUSTER_NAME \
  --cluster_location CLUSTER_LOCATION \
  --fleet_id FLEET_PROJECT_ID \
  --output_dir DIR_PATH \
  --enable_all \
  --custom_overlay user-auth-overlay.yaml

    Os pacotes kpt de autenticação do usuário criam uma AuthorizationPolicy para referenciar ao provedor de autorização externo especificado por pkg/ext-authz.yaml.

  3. Criar e rotular o namespace asm-user-auth.

    kubectl create namespace asm-user-auth
kubectl label namespace asm-user-auth istio.io/rev=REVISION --overwrite

    Para encontrar o valor do rótulo REVISION, verifique kubectl get pod -n istio-system -L istio.io/rev.

  4. Instale o gateway do Istio no namespace asm-user-auth.

    kubectl apply -n asm-user-auth -f DIR_PATH/samples/gateways/istio-ingressgateway

Preparar a configuração do cliente OIDC

Defina a configuração do cliente OIDC usando as etapas a seguir. Este guia usa o Google como IDP, mas é possível usar qualquer IDP que seja compatível com a autenticação OIDC.

  1. No console do Google Cloud, acesse APIs e serviços > Credenciais.

    Ir para Credenciais

  2. Acesse Criar credenciais e escolha ID do cliente do OAuth. Se necessário, defina as opções da tela de permissão do OAuth e configure as seguintes opções:

    • Defina o Tipo de aplicativo como Aplicativo da Web.
    • Defina o URI de redirecionamento autorizado como https://REDIRECT_HOST/REDIRECT_PATH. Por exemplo, para localhost, defina como https://localhost:8443/_gcp_asm_authenticate.

    Clique em Save.

  3. Além disso, salve a configuração do cliente OIDC para usar mais tarde.

    export OIDC_CLIENT_ID=CLIENT_ID
export OIDC_CLIENT_SECRET=CLIENT_SECRET
export OIDC_ISSUER_URI=ISSUER_URI
export OIDC_REDIRECT_HOST=REDIRECT_HOST
export OIDC_REDIRECT_PATH=REDIRECT_PATH

Acessar os pacotes kpt

Use as etapas a seguir para instalar a configuração recomendada de authservice do repositório público. Esses comandos recuperarão o contêiner authservice mais recente e o iniciarão como um pod no namespace asm-user-auth. Ele também configura a entrada para interceptar todas as solicitações.

Acesse o pacote kpt:

kpt pkg get https://github.com/GoogleCloudPlatform/asm-user-auth.git/@v1.2.1 .
cd asm-user-auth/

Definir o URL de redirecionamento e o secret do gateway de entrada

O OAuth2 requer um URL de redirecionamento hospedado em um endpoint protegido por HTTPS. Esses comandos são para fins de exemplo e simplificam a configuração gerando um certificado autoassinado para o gateway de entrada do Istio.

  1. Gerar um certificado autoassinado:

    openssl req -x509 -newkey rsa:4096 -keyout key.pem -out cert.pem \
 -days 365 -nodes -subj '/CN=localhost'

  2. Crie um secret para o gateway de entrada hospedar o tráfego HTTPS:

    kubectl create -n asm-user-auth secret tls userauth-tls-cert --key=key.pem \
--cert=cert.pem

Aplicar as chaves de criptografia e assinatura

O authservice precisa de dois conjuntos de chaves para operar. A primeira é uma chave simétrica para criptografia e descriptografia. Ela é usada para criptografar o estado da sessão antes de defini-lo como um cookie.

O segundo conjunto de chaves é um par de chave pública/privada. Ela é usada para assinar as informações de usuário autenticadas no formato JWT como um RCToken. A chave pública desse par é publicada em um endpoint predefinido que os arquivos secundários podem usar para validar o JWT.

O pacote de autenticação de usuário kpt contém duas chaves de amostra para uma configuração rápida. No entanto, é possível usar o sistema de gerenciamento de chaves que você preferir para gerar essas chaves.

  1. Prepare a chave de criptografia da sessão com o formato a seguir ou use a amostra do pkg, que pode ser visualizado por cat ./samples/cookie_encryption_key.json.

    {
  "keys":[
     {
        "kty":"oct",
        "kid":"key-0",
        "K":"YOUR_KEY",
        "useAfter": 1612813735
     }
  ]
}

    Gere uma chave AES de teste com o seguinte comando:

    openssl enc -aes-256-cbc -k mycustomkey -P -md sha1 | grep key

  2. Prepare a chave de assinatura RCToken com o formato a seguir ou use a amostra do pkg, que pode ser visualizado por cat ./samples/rctoken_signing_key.json.

    {
  "keys":[
     {
        "kty":"RSA",
        "kid":"rsa-signing-key",
        "K":"YOUR_KEY",  # k contains a Base64 encoded PEM format RSA signing key.
        "useAfter": 1612813735  # unix timestamp
     }
  ]
}

    É possível gerar uma chave privada RSA de teste de 256 bits com o seguinte comando:

    openssl genpkey -algorithm RSA -out rsa_private.pem -pkeyopt rsa_keygen_bits:256

  3. Crie o secret do Kubernetes, que authservice montará no próprio sistema de arquivos dele.

    kubectl create secret generic secret-key  \
    --from-file="session_cookie.key"="./samples/cookie_encryption_key.json" \
    --from-file="rctoken.key"="./samples/rctoken_signing_key.json"  \
    --namespace=asm-user-auth

Implantar o serviço de autenticação do usuário

Os comandos a seguir criam o serviço de autenticação do usuário e o implantam no namespace asm-user-auth.

Defina os valores necessários para a configuração da autenticação do usuário. O ID e a chave secreta do cliente são armazenados como segredos do Kubernetes, então usamos a Base64 para codificá-los. Acesse o repositório público para ver todos os setters disponíveis.

kpt fn eval pkg --image gcr.io/kpt-fn/apply-setters:v0.2 --truncate-output=false -- \
  client-id="$(echo -n ${OIDC_CLIENT_ID} | base64 -w0)" \
  client-secret="$(echo -n ${OIDC_CLIENT_SECRET} | base64 -w0)" \
  issuer-uri="${OIDC_ISSUER_URI}" \
  redirect-host="${OIDC_REDIRECT_HOST}" \
  redirect-path="${OIDC_REDIRECT_PATH}"

Aplique o pacote kpt:

# Remove the potential alpha version CRD if exists.
kubectl delete crd userauthconfigs.security.anthos.io
kubectl apply -f ./pkg/asm_user_auth_config_v1beta1.yaml
kubectl apply -f ./pkg

O authservice consome a CRD UserAuthConfig para fornecer autenticação do usuário final. UserAuthConfig é configurável no ambiente de execução, e é possível atualizá-lo para alterar o comportamento de authservice e configurá-lo com endpoints para qualquer servidor de autorização OIDC.

Para visualizar o arquivo por cat pkg/user_auth_config.yaml, ele contém estes campos:

apiVersion: security.anthos.io/v1beta1
kind: UserAuthConfig
metadata:
  name: user-auth-config
  namespace: asm-user-auth
spec:
  authentication:
    oidc:
      certificateAuthorityData: ""  # kpt-set: ${ca-cert}
      issuerURI: "<your issuer uri>"  # kpt-set: ${issuer-uri}
      proxy: ""  # kpt-set: ${proxy}
      oauthCredentialsSecret:
        name: "oauth-secret"  # kpt-set: ${secret-name}
        namespace: "asm-user-auth"  # kpt-set: ${secret-namespace}
      redirectURIHost: ""  # kpt-set: ${redirect-host}
      redirectURIPath: "/_gcp_asm_authenticate"  # kpt-set: ${redirect-path}
      scopes: ""  # kpt-set: ${scopes}
      groupsClaim: ""  # kpt-set: ${groups}
  outputJWTAudience: "test_audience"  # kpt-set: ${jwt-audience}

Consulte detalhes da configuração de autenticação do usuário para ver descrições detalhadas dos campos user_auth_config.yaml.

Realizar tarefas pós-instalação

As tarefas a seguir são necessárias depois que você concluir as etapas de instalação anteriores.

Ativar a autenticação de usuários nos aplicativos

Nesta seção, demonstramos como ativar a autenticação do usuário usando httpbin como exemplo.

A autenticação de usuário do Cloud Service Mesh usa uma política de autorização do tipo CUSTOM para acionar o fluxo do OIDC.

Depois de instalar o gateway do Istio, configure-o para veicular o tráfego HTTPS usando o certificado TLS userauth-tls-cert criado acima. Veja abaixo a configuração de pkg/gateway.yaml que você acabou de instalar.

apiVersion: networking.istio.io/v1beta1
kind: Gateway
metadata:
  name: userauth
  namespace: asm-user-auth
spec:
  selector:
    istio: ingressgateway
  servers:
  - hosts:
    - '*'
    port:
      name: https
      number: 443
      protocol: HTTPS
    tls:
      mode: SIMPLE
      credentialName: userauth-tls-cert

  1. Rotule o namespace default para ativar a injeção automática istio-proxy para as implantações.

    kubectl label namespace default istio.io/rev=REVISION --overwrite

  2. Implantar httpbin no namespace default.

    kubectl apply -f https://raw.githubusercontent.com/istio/istio/master/samples/httpbin/httpbin.yaml -n default

  3. Atualize httpbin para usar esse gateway para exibir tráfego HTTPS e usar encaminhamento de porta para acessar o aplicativo localmente:

    kubectl apply -f./samples/httpbin-route.yaml -n default
kubectl port-forward service/istio-ingressgateway 8443:443 -n asm-user-auth

    O gateway de entrada na porta 8443 será encaminhado para localhost para tornar o aplicativo acessível localmente.

  4. Implante o samples/rctoken-authz.yaml para ativar RequestAuthentication e AuthorizationPolicy para verificar o RCToken para as solicitações.

    kubectl apply -f ./samples/rctoken-authz.yaml -n asm-user-auth

    samples/rctoken-authz.yaml de exemplo:

    apiVersion: security.istio.io/v1beta1
kind: RequestAuthentication
metadata:
  name: require-rc-token
spec:
  selector:
    matchLabels:
      istio: ingressgateway
  jwtRules:
  - issuer: "authservice.asm-user-auth.svc.cluster.local"
    audiences:
    - "test_audience"
    jwksUri: "http://authservice.asm-user-auth.svc.cluster.local:10004/_gcp_user_auth/jwks"
    fromHeaders:
    - name: X-ASM-RCTOKEN
    forwardOriginalToken: true
---
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: require-rc-token
spec:
  selector:
    matchLabels:
      istio: ingressgateway
  action: ALLOW
  rules:
  - when:
    - key: request.auth.claims[iss]
      values:
      - authservice.asm-user-auth.svc.cluster.local
    - key: request.auth.claims[aud]
      values:
      - test_audience

Verificar a autenticação do usuário

O httpbin exibe dois caminhos, /ip é acessível publicamente e /headers requer que o usuário final faça login por meio do IDP configurado.

  1. Verifique se você pode acessar /ip diretamente acessando https://localhost:8443/ip.

  2. Para ver se a página de login do OIDC é exibida, acesse https://localhost:8443/headers.

  3. Depois de fazer login, clique em Próxima e verifique se ele redireciona você para a página /headers.

Configurar políticas de autorização

Depois de concluir a configuração nas etapas anteriores, cada usuário será redirecionado por um fluxo de autenticação baseado na Web. Quando o fluxo for concluído, o authservice gerará um RCToken no formato JWT, usado para transmitir as informações do usuário autenticado.

  1. Adicione políticas de autorização do Istio na entrada para garantir que uma verificação de autorização seja executada para cada usuário autenticado:

    kubectl apply -f ./samples/httpbin-authz.yaml -n asm-user-auth

  2. O arquivo httpbin-authz.yaml configura o gateway de entrada para validar o token de RC emitido pelo authservice e autorizar apenas quando o JWT contiver os campos desejados, como públicos-alvo e emissores.

    Veja o exemplo de política de autorização a seguir:

    apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: require-rc-token
spec:
  selector:
    matchLabels:
      istio: ingressgateway
  action: ALLOW
  rules:
  - to:
    - operation:
        paths: ["/ip"]
  - to:
    when:
    - key: request.auth.claims[iss]
      values:
      - authservice.asm-user-auth.svc.cluster.local
    - key: request.auth.claims[aud]
      values:
      - test_audience
    - key: request.auth.claims[sub]
      values:
      - allowed_user_sub_1  # Change this with the "sub" claim in the RC token. Wildcard '*' will match everything.

Definir configurações específicas do ambiente

As etapas anteriores usam localhost e um certificado HTTPS autoassinado para a configuração rápida. Para uso real na produção, use seu próprio domínio, como example.com.

Além disso, verifique se certificateAuthorityData tem o conteúdo do certificado raiz pretendido. Por exemplo, se o IDP for confiável com os certificados raiz do sistema, você pode deixá-lo vazio. Se houver um proxy HTTPS encerrando a conexão HTTPS, ele precisará ser definido como o certificado raiz do proxy.

Gerenciar e fazer rotação de chaves

Há dois conjuntos de chaves usadas por authservice: É possível fazer a rotação de cada chave de maneira independente. No entanto, antes de fazer a rotação das chaves, é importante entender como a rotação funciona.

As duas chaves estão no formato JSON. O campo useAfter especifica o carimbo de data/hora desde quando a chave for considerada em uso. Durante uma rotação de chaves, inclua chaves antigas e novas no JSON. No exemplo a seguir, new-key será usada apenas depois do carimbo de data/hora 1712813735.

{
   "keys":[
      {
         "kty":"RSA",
         "kid":"old-key",
         "K":"...", # k contains a Base64 encoded PEM format RSA signing key.
         "useAfter": 1612813735, # unix timestamp
      }
      {
      "kty":"RSA",
         "kid":"new-key",
         "K":"...", # k contains a Base64 encoded PEM format RSA signing key.
         "useAfter": 1712813735, # unix timestamp
      }
   ]
}

O Cloud Service Mesh usa a chave simétrica para criptografar dados de sessão armazenados em cookies do navegador. Para garantir a validade de sessões existentes, authservice tenta descriptografar com todas as chaves no conjunto de chaves. Na rotação, o authservice usará a nova chave para criptografar novas sessões e continuará tentando fazer a descriptografia com as chaves antigas.

O par de chave pública/privada é usado para assinar RCToken. A chave pública é transmitida para os arquivos secundários por istiod para verificação do JWT. É fundamental que os arquivos secundários recebam a nova chave pública antes que authservice comece a usar a nova chave privada para assinar o RCToken. Para isso, authservice começa a publicar a chave pública imediatamente após a adição dela, mas aguarda um tempo significativo antes de começar a usá-la para assinar o RCToken.

Para resumir, ao executar a rotação de chaves, recomendamos:

  1. Faça rotações regulares de chaves ou sob demanda, conforme necessário.
  2. No formato JSON, inclua as chaves atuais e novas. As novas chaves serão associadas a um carimbo de data/hora no futuro. Recomendamos que você especifique um carimbo de data/hora com pelo menos algumas horas de antecedência.
  3. Monitore e confirme se os serviços ainda estão íntegros depois que a nova chave está em uso. Aguarde pelo menos um dia depois de a nova chave ser usada antes de passar para a próxima etapa.
  4. Remova as chaves antigas das entradas JSON. Eles não são mais necessários.

Implantação de vários clusters

A autenticação de usuário do Cloud Service Mesh é compatível com a implantação de vários clusters. É necessário implantar a autenticação do usuário em cada cluster, conforme descrito acima. A configuração de autenticação do usuário, como o recurso personalizado UserAuth, a chave secreta do cliente OIDC, as chaves de criptografia, todos precisam ser replicados em cada cluster.

Por padrão, o gateway de entrada balanceará a carga das solicitações de autenticação para qualquer uma das instâncias authservice. É possível usar a regra de destino para configurar o gateway de entrada para enviar solicitações ao authservice no mesmo cluster e fazer failover apenas para o authservice de outros clusters.

apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: authservice-fail-over
  namespace: asm-user-auth
spec:
  host: authservice.asm-user-auth.svc.cluster.local
  trafficPolicy:
    loadBalancer:
      localityLbSetting:
        enabled: true
        failover:
        - from:  us-east
          to: us-west
        - from: us-west
          to: us-east

Assim como outras configurações, isso precisa ser definido em cada cluster.

Mapeamento de declarações personalizadas

Se você quiser configurar o mapeamento de declarações personalizadas, configure o spec.authentication.oidc.attributeMapping para definir qualquer mapeamento do IDToken do provedor de identidade original. A chave será o nome da reivindicação no RCToken, e o valor é uma expressão CEL sobre como analisar a declaração do IDToken. Use assertion para fazer referência ao IDToken.

Exemplo:

spec:
  authentication:
    oidc:
      attributeMapping:
        aud_copy: assertion.aud
        decision: 'assertion.sub.startsWith("123") ? "success" : "fail"'

No RCToken, uma reivindicação aninhada attributes contém as reivindicações que foram configuradas:

"attributes": {
    "aud_copy": "foo.googleusercontent.com",
    "decision": "success"
}

Se a expressão CEL não analisar o valor do IDToken, ela vai ignorar a declaração sem falhar no fluxo de autenticação.

Upgrades da autenticação de usuário

  1. Instale os pacotes de autenticação do usuário novamente porque eles contêm o binário atualizado para a nova versão:

    kpt pkg get https://github.com/GoogleCloudPlatform/asm-user-auth.git/@v1.2.1 .
cd asm-user-auth/

  2. Salve a configuração do cliente do OIDC:

    export OIDC_CLIENT_ID=CLIENT_ID
export OIDC_CLIENT_SECRET=CLIENT_SECRET
export OIDC_ISSUER_URI=ISSUER_URI
export OIDC_REDIRECT_HOST=REDIRECT_HOST
export OIDC_REDIRECT_PATH=REDIRECT_PATH

  3. Implante o serviço de autenticação de usuário para fazer upgrade para uma nova versão.

Detalhes da configuração de autenticação do usuário

A tabela a seguir descreve cada campo do CRD:

Nome do campo Descrição
authentication.oidc Nesta seção, mostramos a configuração do endpoint do OIDC e os parâmetros usados no fluxo do OIDC.
authentication.oidc.certificateAuthorityData Este é o certificado raiz SSL do domínio do servidor de autorização OIDC ou do proxy HTTPS, se houver.
authentication.oidc.oauthCredentialsSecret Referências do secret para o secret de tipo opaco do Kubernetes que contém o OAuth2 OIDC client_id e client_secret no payload JSON.
authentication.oidc.issuerURI O URI a ser usado como o emissor na saída RCToken.
authentication.oidc.proxy Servidor proxy para o IdP do OIDC, se aplicável. Com o formato http://user:password@10.10.10.10:8888.
authentication.oidc.redirectURIHost O host a ser usado para o URI de encerramento do OAuth. Se você deixar esse campo vazio, o host do URL de destino será usado, e o URI de redirecionamento será montado dinamicamente.
Esse valor pode ser usado quando uma sessão de SSO de autenticação de usuário é desejada em um domínio de nível mais alto. Por exemplo, para ativar o SSO entre perfil.example.com/ e admin.example.com/, esse valor pode ser definido como example.com. Isso permitirá que uma sessão de autenticação do usuário seja estabelecida em example.com que será compartilhada entre todos os subdomínios. Observação: se vários domínios forem exibidos na mesma malha, example1.com e example2.com, o recurso não poderá ser usado e é recomendado que fique vazio.
authentication.oidc.redirectURIPath O caminho do endpoint onde authservice encerrará o fluxo do OAuth. É necessário registrar esse caminho de URI mais o host como um URI de redirecionamento autorizado no servidor de autorização do authentication.oidc.clientID.
Além disso, esse URI precisa ser exibido na mesma malha de serviço e entrada em que authservice estiver ativado.
authentication.oidc.scopes O escopo do OAuth que precisa ser solicitado na solicitação de autenticação. Lista de identificadores separados por vírgulas usados para especificar quais privilégios de acesso estão sendo solicitados, além do escopo "openid", por exemplo: "groups,allatclaim".
authentication.oidc.groupsClaim Se idtoken contiver uma declaração de grupos, use este campo para indicar o nome. Se especificado, o serviço transmitirá os dados dessa declaração na declaração groups no RCToken de saída. Essa declaração deve conter uma lista separada por vírgulas, por exemplo, ["grupo1", "grupo2"].
authentication.oidc.attributeMapping Contém um ou mais mapeamentos de declaração de idtoken seguidos de expressões de CEL. Todas as declarações precisam ser referenciadas por assertion.X, assertion é referenciada ao IDToken original, por exemplo, aud_copy: assertion.aud..
authentication.outputJWTAudience O público-alvo do RCToken gerado por authservice. Os arquivos secundários podem validar o RCToken de entrada em relação a esse valor de público-alvo.

Resolver problemas

  1. Acessibilidade da rede para IDP.

    Registro possível: error: TLS handshake failed..

    Verifique executando curl do contêiner istio-proxy para o URI do emissor do IDP. Se não conseguir se conectar, o usuário poderá verificar as regras de firewall ou outras configurações de rede do cluster.

  2. Certificado de CA raiz

    Registro possível: error: The server's TLS certificate did not match expectations. ou error: TLS handshake failed..

    Verifique se o certificateAuthorityData contém o certificado de CA raiz correto. Quando não houver nenhum proxy HTTPS encerrando o tráfego HTTPS, será necessário manter o certificado de CA raiz para o IdP. Se houver um, ele deverá manter o do proxy.

  3. Redirecione a configuração do caminho.

    Possível observação: receba a página de erro 404 durante o fluxo de autenticação do OIDC.

    A autenticação do usuário retorna o cabeçalho "Set-Cookie" sem usar o atributo de caminho, que, por padrão, o navegador usa o diretório do URL de solicitação como caminho do cookie (escopo do cookie relacionado ao caminho). Portanto, recomendamos não incluir "/" no caminho de redirecionamento, a menos que seja intencional.

  4. O arquivo secundário não pode buscar jwksUri.

    Em alguns cenários, uma restrição de arquivo secundário pode levar à falha de busca do jwksUri. Se o namespace não estiver presente usando um caractere curinga (por exemplo, ./* ou istio-system/*), ele não funcionará. Você precisa adicionar manualmente o namespace no arquivo secundário de saída.

Perguntas frequentes

  1. Como faço upgrade do Cloud Service Mesh com a autenticação de usuário ativada?

    Siga o processo de upgrade do Cloud Service Mesh e especifique o arquivo de sobreposição adicionando --custom_overlay user-auth-overlay.yaml na linha de comando a asmcli install.

  2. Quantos recursos devemos provisionar para o authservice? E quantas solicitações por segundo ele consegue processar?

    Por padrão, authservice é configurado com 2.0 vCPUs, 256 Mi de memória. Nessa configuração, authservice pode processar 500 solicitações por segundo. Para processar uma quantidade maior de solicitações, provisione mais CPU, que é aproximadamente proporcional à capacidade de processamento de solicitações. Também é possível configurar várias réplicas do serviço de autenticação para aumentar a escalonabilidade horizontal.