Configurar a autenticação de utilizadores da malha de serviço na nuvem

A autenticação de utilizadores da Cloud Service Mesh é uma solução integrada para a autenticação de utilizadores finais baseada no navegador e o controlo de acesso aos seus cargas de trabalho implementados. Permite-lhe integrar-se com fornecedores de identidade (IDP) existentes para a autenticação de utilizadores e usa APIs Istio e políticas de autorização para a gestão de acesso. É uma alternativa fácil de usar à autenticação do símbolo da Web JSON (JWT) do Istio.

Um exemplo de utilização típico é quando uma organização usa a malha de serviços na nuvem para alojar uma aplicação Web para que os seus funcionários acedam através de um navegador de Internet. Além disso, a organização tem de usar o respetivo fornecedor de identidade existente para gerir as identidades dos utilizadores. A autenticação de utilizadores da Cloud Service Mesh facilita a autenticação dos utilizadores através de um fluxo de consentimento e início de sessão OpenID Connect (OIDC) padrão baseado na Web. Quando o utilizador autentica, o Cloud Service Mesh aplica políticas de autorização do Istio e, após a autorização bem-sucedida, transmite a identidade para cargas de trabalho num formato de credenciais seguro.

Como funciona

A autenticação de utilizadores do Cloud Service Mesh introduz um novo componente, authservice. Este componente integra-se com a entrada baseada no Envoy como um serviço de autorização externo que interceta todos os pedidos recebidos para autenticação. authservice implementa o lado do cliente do protocolo OIDC e permite o acesso dos utilizadores a aplicações através de um navegador, onde os utilizadores concluem um fluxo de consentimento e autenticação interativo para estabelecer uma sessão de curta duração. O authservice implementa protocolos da norma da indústria para integração com qualquer fornecedor de identidade que possa atuar como um servidor de autorização OIDC. Quando o utilizador é autenticado, as informações principais são encapsuladas num RCToken no formato JWT, assinado por authservice, que encaminha para a camada de autorização do Istio na entrada. Este modelo oferece controlo de acesso ao perímetro para o tráfego na malha. Se o utilizador estiver autorizado a aceder a um recurso, este RCToken também é encaminhado para os microsserviços para obter informações principais e aplicar o controlo de acesso detalhado.

O diagrama seguinte mostra a localização do authservice na malha e a sua relação com as outras partes da malha, como a entrada, as cargas de trabalho, o navegador do utilizador e qualquer IDP existente.

autenticação do utilizador final

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

Instale o serviço de autenticação do utilizador

Os passos seguintes explicam como configurar o authservice.

Pré-requisitos

Siga os passos em Instale ferramentas dependentes e valide o cluster para:

  • Se estiver a usar o Cloud Service Mesh gerido num cluster privado, certifique-se de que o cluster consegue enviar tráfego de saída para o IDP.

  • Transfira o pacote kpt:

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

    Este comando obtém um pacote kpt com a configuração authservice recomendada do repositório público. O pacote contém manifestos para implementar o contentor authservice como um pod no espaço de nomes asm-user-auth. Também configura o gateway de entrada para exigir autorização para todos os pedidos.

Configure um fornecedor de autorização externo e implemente um gateway de entrada

Para instalar o serviço de autenticação de utilizadores, personaliza a instalação do Cloud Service Mesh para adicionar um fornecedor de autorização externo. Os passos necessários dependem de estar a usar o Cloud Service Mesh gerido ou no cluster.

Gerido

  1. Atualize a configuração da malha no Istio ConfigMap para adicionar um fornecedor de autorização externo. No comando seguinte, use o mesmo REVISION_LABEL que usou quando aprovisionou o Cloud Service Mesh gerido (como asm-managed, asm-managed-rapid ou asm-managed-stable):

    kubectl edit configmap istio-REVISION_LABEL -n istio-system

  2. Adicione o fornecedor da extensão no campo mesh:

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

  3. Crie e etiquete o espaço de nomes asm-user-auth.

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

  4. Instale um gateway de entrada no espaço de nomes asm-user-auth.

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

No cluster

  1. Obtenha o exemplo da sobreposição de autorização do utilizador e atualize-o se houver personalizações na sua malha. É uma prática recomendada manter este ficheiro de sobreposição no seu controlo de origem.

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

  2. Siga as instruções para instalar o Cloud Service Mesh com sobreposição para usar um script fornecido pela Google para instalar o Cloud Service Mesh com a sobreposição de autenticação do utilizador. Por 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 de kptautenticação do utilizador criam um AuthorizationPolicy para referenciar o fornecedor de autorização externo especificado por pkg/ext-authz.yaml.

  3. Crie e etiquete o espaço de nomes asm-user-auth.

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

    Pode encontrar o valor da etiqueta REVISION verificando kubectl get pod -n istio-system -L istio.io/rev

  4. Instale o gateway do Istio no espaço de nomes asm-user-auth.

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

Prepare a configuração do cliente OIDC

Defina a configuração do cliente OIDC através dos seguintes passos. Este guia usa a Google como um IdP, mas pode usar qualquer IdP que suporte a autenticação OIDC.

  1. Na Google Cloud consola, aceda a APIs e serviços > Credenciais.

    Aceder a Credenciais

  2. Aceda a Criar credenciais e, de seguida, escolha ID de cliente OAuth. Se necessário, defina as opções do ecrã de consentimento OAuth e, em seguida, configure as seguintes opções:

    • Defina o Tipo de aplicação como Aplicação Web.
    • Defina o URI de redirecionamento autorizado para https://REDIRECT_HOST/REDIRECT_PATH. Por exemplo, para localhost, pode definir como https://localhost:8443/_gcp_asm_authenticate.

    De seguida, clique em Guardar.

  3. Além disso, guarde 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

Defina o URL de redirecionamento e o segredo para o gateway de entrada

OAuth2 requer um URL de redirecionamento alojado num ponto final protegido por HTTPS. Estes comandos destinam-se a fins de exemplo e simplificam a configuração gerando um certificado autoassinado para o gateway de entrada do Istio.

  1. Gere um certificado autoassinado:

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

  2. Crie um segredo para o gateway de entrada para alojar tráfego HTTPS:

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

Aplique as chaves de encriptação e assinatura

O authservice precisa de dois conjuntos de chaves para funcionar com êxito. A primeira é uma chave simétrica para encriptação e desencriptação. Esta chave é usada para encriptar o estado da sessão antes de o definir como um cookie.

O segundo conjunto de chaves é um par de chaves públicas/privadas. Esta chave é usada para assinar as informações do utilizador autenticado no formato JWT como um RCToken. A chave pública deste par é publicada num ponto final predefinido que os sidecars podem usar para validar o JWT.

O pacote de kptautenticação do utilizador contém duas chaves de exemplo para uma configuração rápida. No entanto, pode usar o seu sistema de gestão de chaves preferido para gerar estas chaves.

  1. Prepare a chave de encriptação da sessão com o seguinte formato ou use o exemplo do pacote, que pode ver cat ./samples/cookie_encryption_key.json.

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

    Pode gerar uma chave AES de teste com o seguinte comando:

    openssl rand -base64 32

  2. Prepare a chave de assinatura do RCToken com o seguinte formato ou use o exemplo do pacote, que pode ver cat ./samples/rctoken_signing_key.json.

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

    Pode gerar uma chave privada RSA de 256 bits de teste com o seguinte comando:

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

  3. Crie o segredo do Kubernetes, que o authservice vai montar no respetivo sistema de ficheiros.

    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

Implemente o serviço de autenticação de utilizadores

Os seguintes comandos criam o serviço de autenticação de utilizadores e a implementação no espaço de nomes asm-user-auth.

Defina os valores necessários para a configuração da autenticação do utilizador. O ID do cliente e o segredo são armazenados como segredos do Kubernetes, pelo que usamos o Base64 para os codificar. Visite o repositório público para ver todos os definidores 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 o CRD UserAuthConfig para fornecer autenticação ao utilizador final. UserAuthConfig é configurável no tempo de execução e pode atualizá-lo para alterar o comportamento de authservice e configurá-lo com pontos finais para qualquer servidor de autorização OIDC.

Pode ver o ficheiro por cat pkg/user_auth_config.yaml. Este contém os seguintes 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 os detalhes da configuração da autenticação do utilizador para ver descrições detalhadas dos campos user_auth_config.yaml.

Executar tarefas pós-instalação

As seguintes tarefas são necessárias depois de concluir os passos de instalação.

Ative a autenticação do utilizador para as suas aplicações

Esta secção demonstra como ativar a autenticação do utilizador através da aplicação de exemplo httpbin.

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

Depois de instalar o gateway Istio, configure-o para publicar tráfego HTTPS através do certificado TLS userauth-tls-cert que criou acima. Abaixo, encontra a configuração do pkg/gateway.yaml que 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
---
# This ensures the OIDC endpoint has at least some route defined.
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: userauth-oidc
  namespace: asm-user-auth
spec:
  gateways:
  - userauth
  hosts:
  - '*'
  http:
  - match:
    - uri:
        prefix: /status
    - uri:
        prefix: "your-oidc-redirect-path"
    name: user-auth-route
    route:
    - destination:
        host: authservice
        port:
          number: 10004

  1. Etiquete o espaço de nomes default para ativar a injeção automática de istio-proxy para implementações.

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

  2. Implemente httpbin no espaço de nomes default.

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

  3. Atualize o httpbin para usar este gateway para publicar tráfego HTTPS e use o encaminhamento de portas para aceder à aplicação localmente:

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

    apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: httpbin
  namespace: default
spec:
  gateways:
  - asm-user-auth/userauth
  hosts:
  - '*'
  http:
  - match:
    - uri:
        prefix: /ip
    - uri:
        prefix: /headers
    name: httpbin-routes
    route:
    - destination:
        host: httpbin.default.svc.cluster.local
        port:
          number: 8000

    O gateway de entrada na porta 8443 vai ser encaminhado para localhost para tornar a aplicação acessível localmente.

  4. Implemente o samples/rctoken-authz.yaml para ativar o RequestAuthentication e a AuthorizationPolicy para validar o RCToken dos pedidos.

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

    Exemplo samples/rctoken-authz.yaml:

    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

Valide a autenticação do utilizador

O httpbin serve dois caminhos. O /ip é acessível publicamente e o /headers requer que o utilizador final inicie sessão através do respetivo IdP configurado.

  1. Confirme se consegue aceder diretamente ao /ip visitando https://localhost:8443/ip.

  2. Verifique se vê a página de início de sessão do OIDC visitando https://localhost:8443/headers.

  3. Depois de iniciar sessão, clique em Seguinte e verifique se é feito o redirecionamento para a página /headers.

Configure políticas de autorização

Depois de concluir a configuração nos passos anteriores, cada utilizador é redirecionado através de um fluxo de autenticação baseado na Web. Quando o fluxo estiver concluído, o authservice gera um RCToken no formato JWT, que usa para transmitir as informações do utilizador autenticado.

  1. Adicione políticas de autorização do Istio na entrada para garantir que é feita uma verificação de autorização para cada utilizador autenticado:

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

  2. O ficheiro httpbin-authz.yaml configura o gateway de entrada para validar o token RC emitido pelo authservice e só autorizar quando o JWT contém os campos pretendidos, como públicos-alvo e emissoras.

    Veja o exemplo seguinte de uma política de autorização:

    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.

Configure definições específicas do ambiente

Os passos anteriores usam o localhost e um certificado HTTPS autoassinado para uma configuração rápida. Para utilização real em produção, use o seu próprio domínio, como example.com.

Além disso, certifique-se de que o certificateAuthorityData tem o conteúdo do certificado de raiz pretendido. Por exemplo, se o IDP for fidedigno com os certificados de raiz do sistema, pode deixá-lo vazio. Se existir um proxy HTTPS a terminar a ligação HTTPS, este deve ser definido para o certificado de raiz do proxy.

Faça a gestão e alterne as chaves

O authservice usa dois conjuntos de chaves. Pode rodar cada tecla de forma independente. No entanto, antes de rodar as chaves, é importante compreender como funciona a rotação.

Ambas as chaves estão no formato JSON. O campo useAfter especifica a data/hora desde a qual a chave vai ser considerada para utilização. Durante uma rotação de chaves, deve incluir as chaves antigas e novas no JSON. Por exemplo, no exemplo seguinte, new-key só é usado após a 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 encriptar os dados da sessão que são armazenados em cookies do navegador. Para garantir a validade das sessões existentes, authservice tenta a desencriptação com todas as chaves no conjunto de chaves. Na rotação, o authservice usa a nova chave para encriptar novas sessões e continua a tentar desencriptar com as chaves antigas.

O par de chaves pública/privada é usado para assinar RCToken. A chave pública é transmitida aos sidecars por istiod para validação de JWT. É fundamental que os sidecars recebam a nova chave pública antes de authservice começar a usar a nova chave privada para assinar o RCToken. Para esse efeito, authservice começa a publicar a chave pública imediatamente após a adição da chave, mas aguarda um período de tempo significativo antes de começar a usá-la para assinar RCToken.

Em resumo, quando realizar rotações de chaves, recomendamos o seguinte:

  1. Faça rotações de chaves regulares ou a pedido, conforme necessário.
  2. No formato JSON, inclua as chaves atuais e as novas. As novas chaves devem estar associadas a uma data/hora no futuro. Recomendamos que especifique uma data/hora, pelo menos, algumas horas antes da hora atual.
  3. Monitorize e confirme que os serviços continuam a funcionar corretamente depois de a nova chave estar em utilização. Aguarde, pelo menos, um dia após a utilização da nova chave antes de avançar para o passo seguinte.
  4. Remova as chaves antigas das entradas JSON. Já não são necessários.

Implementação em vários clusters

A autenticação de utilizadores do Cloud Service Mesh suporta a implementação em vários clusters. Tem de implementar a autenticação do utilizador em cada cluster, conforme descrito acima. A configuração de autenticação do utilizador, como o recurso personalizado UserAuth, o segredo do cliente OIDC e as chaves de encriptação, tem de ser replicada em cada cluster.

Por predefinição, o gateway de entrada equilibra a carga dos pedidos de autenticação para qualquer uma das instâncias do authservice. Pode usar uma regra de destino para configurar o gateway de entrada de modo a enviar pedidos para o authservice no mesmo cluster e só fazer failover 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

Tal como noutras configurações, tem de configurar isto em cada cluster.

Mapeamento de reivindicações personalizado

Para configurar o mapeamento de reivindicações personalizadas, configure spec.authentication.oidc.attributeMapping para definir quaisquer mapeamentos do IDToken do fornecedor de identidade original. A chave vai ser o nome da reivindicação no RCToken e o valor é uma expressão CEL sobre como analisar a reivindicaçã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 conseguir analisar o valor do IDToken, ignora a reivindicação sem falhar o fluxo de autenticação.

Atualizações de autenticação de utilizadores

  1. Instale novamente os pacotes user-auth, uma vez que contêm o binário atualizado para a nova versão user-auth:

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

  2. Guarde a configuração do cliente 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. Implemente o serviço de autenticação do utilizador para atualizar para uma nova versão.

Detalhes da configuração da autenticação de utilizadores

A tabela seguinte descreve cada campo no CRD:

Nome do campo Descrição
authentication.oidc Esta secção contém a configuração do ponto final do OIDC e os parâmetros usados no fluxo do OIDC.
authentication.oidc.certificateAuthorityData Este é o certificado de raiz SSL do domínio do servidor de autorização OIDC ou do proxy HTTPS, se existir.
authentication.oidc.oauthCredentialsSecret Referências secretas ao segredo do tipo opaco do Kubernetes que contém o client_id e o client_secret do OAuth2 OIDC na carga útil JSON.
authentication.oidc.issuerURI O URI a usar como emissor no RCToken de saída.
authentication.oidc.proxy Servidor proxy para o IDP OIDC, se aplicável. Com o formato http://user:password@10.10.10.10:8888.
authentication.oidc.redirectURIHost O anfitrião a usar para o URI de terminação do OAuth. Se deixar este campo vazio, é usado o anfitrião do URL de destino e o URI de redirecionamento é montado dinamicamente.
Este valor pode ser usado quando se pretende uma sessão de SSO de autenticação de utilizador num domínio de nível superior. Por exemplo, para ativar o SSO entre profile.example.com/ e admin.example.com/, este valor pode ser definido como example.com. Vai permitir que seja estabelecida uma sessão de autenticação de utilizador em example.com que será partilhada entre todos os subdomínios. Nota: se forem publicados vários domínios a partir da mesma malha, por exemplo, example1.com e example2.com, não é possível usar a funcionalidade e recomenda-se que a deixe vazia.
authentication.oidc.redirectURIPath O caminho do ponto final onde authservice termina o fluxo OAuth. Deve registar este caminho de URI, bem como o anfitrião, como um URI de redirecionamento autorizado no servidor de autorização para o authentication.oidc.clientID.
Além disso, este URI deve ser publicado a partir da mesma malha de serviços e entrada onde authservice está ativado.
authentication.oidc.scopes O âmbito do OAuth que deve ser pedido no pedido de autenticação. Lista separada por vírgulas de identificadores usados para especificar os privilégios de acesso que estão a ser pedidos, além do âmbito "openid", por exemplo: "groups,allatclaim".
authentication.oidc.groupsClaim Se o idtoken contiver uma reivindicação de grupos, use este campo para indicar o respetivo nome. Se especificado, o serviço transmite os dados nesta reivindicação para a reivindicação groups no RCToken de saída. Esta reivindicação deve conter uma lista de strings separadas por vírgulas, por exemplo: ["group1", "group2"].
authentication.oidc.attributeMapping Contém um ou mais mapeamentos de reivindicações de idtoken seguidos de expressões CEL. Todas as reivindicações devem ser referenciadas por assertion.X. assertion é referenciado ao IDToken original, por exemplo, aud_copy: assertion.aud.
authentication.outputJWTAudience O público-alvo do RCToken gerado por authservice. Os sidecars podem validar o RCToken recebido em relação a este valor de público-alvo.

Resolver problemas

  1. Acessibilidade da rede ao IDP.

    Possível registo: error: TLS handshake failed..

    Valide a execução de curl a partir do contentor istio-proxy para o URI do emissor do IDP. Se não conseguir estabelecer ligação, o utilizador pode verificar as regras da firewall ou outras configurações de rede para o cluster.

  2. Certificado da AC de raiz.

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

    Certifique-se de que o certificateAuthorityData tem o certificado de CA de raiz correto. Quando não existe um proxy HTTPS a terminar o tráfego HTTPS, este deve conter o certificado de CA raiz para o IDP. Se existir, deve conter os proxies.

  3. Configuração do caminho de redirecionamento.

    Possível observação: recebe uma página de erro 404 durante o fluxo de autenticação OIDC.

    A autenticação do utilizador devolve o cabeçalho "Set-Cookie" sem usar o atributo path, que, por predefinição, o navegador usa o diretório do URL do pedido como o caminho do cookie (âmbito do cookie relacionado com o caminho). Por isso, recomendamos que não inclua "/" no caminho de redirecionamento, a menos que seja essa a sua intenção.

  4. O sidecar não consegue obter o jwksUri.

    Em alguns cenários, uma restrição de sidecar pode levar à falha da obtenção de jwksUri. Se o espaço de nomes não estiver presente com um caráter universal (por exemplo, ./* ou istio-system/*), isto não funciona. Tem de adicionar manualmente o respetivo espaço de nomes no sidecar de saída.

Perguntas frequentes

  1. Como posso atualizar o Cloud Service Mesh com a autenticação de utilizadores ativada?

    Se estiver a usar o Cloud Service Mesh no cluster, siga o processo de atualização do Cloud Service Mesh e especifique o ficheiro de sobreposição adicionando --custom_overlay user-auth-overlay.yaml na linha de comandos para asmcli install.

    O Managed Cloud Service Mesh é atualizado automaticamente.

  2. Quanta CPU e memória devo aprovisionar para o authservice? E quantos pedidos por segundo consegue processar?

    Por predefinição, authservice está configurado com 2, 0 vCPU e 256 Mi de memória. Com esta configuração, o authservice consegue processar 500 pedidos por segundo. Para processar maiores quantidades de pedidos, deve aprovisionar mais CPU, o que é aproximadamente proporcional à respetiva capacidade de processamento de pedidos. Também pode configurar várias réplicas do authservice para aumentar a escalabilidade horizontal.