Você está vendo a documentação da Service Mesh v1.22.

Versões disponíveis

Cloud Service Mesh
1.22 archive
1.21 archive
1.20 archive
1.19 archive
1.18 archive

Esta página foi traduzida pela API Cloud Translation.

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

Se você estiver usando essa implementação, faça mudanças no configmap istio-asm-managed-rapid, mesmo que esteja usando um canal diferente do rápido.

Se você tiver a TRAFFIC_DIRECTOR implementação do plano de controle esse recurso só é compatível com a lista de permissões. Entre em contato com o suporte para solicitar acesso.

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 que a força de trabalho pode acessar por 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ários 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 se autentica, o Cloud Service Mesh aplica o Istio e, em caso de autorização, transmite a a 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 um Cloud Service Mesh e instalação. 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 de você estar usando o Cloud Service Mesh gerenciado ou no cluster.

Gerenciado

Atualize o ConfigMap para incluir o MeshConfig de autenticação do usuário. No comando a seguir, use a mesma REVISION_LABEL usada para provisionamento do Cloud Service Mesh gerenciado (por exemplo, asm-managed, asm-managed-rapid, ou asm-managed-stable):
```
kubectl edit configmap istio-REVISION_LABEL -n istio-system
```

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"

Crie o namespace asm-user-auth.
```
kubectl create namespace asm-user-auth
```
Ativar o namespace para injeção. As etapas dependem da implementação do plano de controle.
Gerenciado (TD)
Aplique o rótulo de injeção padrão ao namespace:
```
kubectl label namespace asm-user-auth \
    istio.io/rev- istio-injection=enabled --overwrite
```
Gerenciado (Istiod)
Recomendado:execute o seguinte comando para aplicar o rótulo de injeção padrão ao namespace:
```
```sh
kubectl label namespace asm-user-auth \
    istio.io/rev- istio-injection=enabled --overwrite
```
```
Se você for um usuário com o plano de controle Managed Istiod: Recomendamos que você use a injeção padrão, mas a injeção baseada em revisão é suporte. Siga estas instruções:
1. Execute o seguinte comando para localizar os canais de lançamento disponíveis:
```
kubectl -n istio-system get controlplanerevision
```
O resultado será assim:
```
NAME                AGE
asm-managed-rapid   6d7h
```
Observação: se duas revisões do plano de controle aparecerem na lista acima, remova uma. Não é possível ter vários canais de plano de controle no cluster.

Na saída, o valor na coluna NAME é o rótulo de revisão que corresponde ao canal de lançamento disponível para a versão do Cloud Service Mesh.
1. Aplique o rótulo de revisão ao namespace:
  kubectl label namespace asm-user-auth \ istio-injection- istio.io/rev=REVISION_LABEL --overwrite
Instale o gateway do Istio no namespace asm-user-auth.
```
kubectl apply -n asm-user-auth -f DIR_PATH/samples/gateways/istio-ingressgateway
```
Observação: DIR_PATH refere-se ao local do repositório anthos-service-mesh-packages na sua máquina. Se você não tiver este repositório na sua máquina, clone-o: git clone https://github.com/GoogleCloudPlatform/anthos-service-mesh-packages.git

No cluster

Confira o exemplo sobreposição de autenticação do usuário e atualize-a caso haja personalizações na sua 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.3/overlay/user-auth-overlay.yaml > user-auth-overlay.yaml
```
Siga as instruções em Instalar o Cloud Service Mesh com sobreposição para usar um script fornecido pelo Google para instalar o Cloud Service Mesh com o usuário sobreposição de autenticação. 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
```
Importante: se você personalizar a instalação com várias sobreposições, verifique se a opção --custom_overlay inclui todos os arquivos de sobreposição.

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.
Crie o namespace asm-user-auth.
```
kubectl create namespace asm-user-auth
```
Ativar o namespace para injeção.

Recomendado: execute o comando a seguir para aplicar o rótulo de injeção padrão ao namespace:
```
  kubectl label namespace asm-user-auth \
      istio.io/rev- istio-injection=enabled --overwrite
```
Recomendamos que você use a injeção padrão, mas a injeção baseada em revisão tem suporte: Siga estas instruções:
1. Use o seguinte comando para localizar o rótulo de revisão em istiod:
```
kubectl get deploy -n istio-system -l app=istiod -o \
  jsonpath={.items[*].metadata.labels.'istio\.io\/rev'}'{"\n"}'
```
2. Aplique o rótulo de revisão ao namespace. No comando a seguir, REVISION_LABEL é o valor do rótulo de revisão istiod que você anotou na etapa anterior.
```
kubectl label namespace asm-user-auth \
    istio-injection- istio.io/rev=REVISION_LABEL --overwrite
```
Instale o gateway do Istio no namespace asm-user-auth.
```
kubectl apply -n asm-user-auth -f DIR_PATH/samples/gateways/istio-ingressgateway
```
Observação: DIR_PATH se refere ao local do repositório anthos-service-mesh-packages na máquina. Se você não tiver esse repositório na sua máquina, clone-o: git clone https://github.com/GoogleCloudPlatform/anthos-service-mesh-packages.git

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.

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

Ir para Credenciais
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.

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.3 .
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.

Gerar um certificado autoassinado:

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

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.

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

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

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
---
# 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

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
```

Implantar httpbin no namespace default.

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

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

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 será encaminhado para localhost para tornar o aplicativo acessível localmente.

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.

Verifique se você pode acessar /ip diretamente acessando https://localhost:8443/ip.
Para ver se a página de login do OIDC é exibida, acesse https://localhost:8443/headers.
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.

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
```

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:

Faça rotações regulares de chaves ou sob demanda, conforme necessário.
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.
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.
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 oferece suporte à 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

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.3 .
cd asm-user-auth/
```

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

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

Acessibilidade da rede para IDP.

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

Verifique executando curl no contêiner temporário anexado ao istio-proxy para chamar URI do emissor do IdP. Por exemplo, consulte Como coletar registros do Cloud Service Mesh.

Se não for possível se conectar, verifique as regras de firewall ou outras configurações de rede do cluster.
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.
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.
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

Como fazer upgrade do Cloud Service Mesh com a autenticação do 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.
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.