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

A autenticação do usuário do Anthos Service Mesh é uma solução integrada para autenticação e controle de acesso do usuário final baseada no 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 Anthos 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 do usuário do Anthos 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 Anthos 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 Anthos 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 Ingress. 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.

Os administradores podem instalar o authservice como um complemento em uma instalação do Anthos 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 Anthos 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

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

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

Para instalar o serviço de autenticação do usuário, personalize a instalação do ASM para adicionar um provedor de autorização externa no nível da malha.

1. Veja 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/release-1.0/overlay/user-auth-overlay.yaml > user-auth-overlay.yaml
   

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

   /install_asm \
    --project_id "PROJECT_ID" \
    --cluster_name "CLUSTER_NAME" \
    --cluster_location "CLUSTER_LOCATION" \
    --mode install \
    --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.

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 consentimento 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://localhost:8443/_gcp_anthos_callback.

   Clique em Save.

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

   export OIDC_CLIENT_ID='<your-client-id>'
   export OIDC_CLIENT_SECRET='<your-client-secret>'
   export OIDC_ISSUER_URI='https://accounts.google.com'
   # The host where your application is served from, such as https://example.com
   export OIDC_REDIRECT_HOST='<your-oidc-redirect-host>'
   export OIDC_REDIRECT_PATH='<your-oidc-redirect-path>'
   

Acessar os pacotes kpt

Use as etapas a seguir para instalar a configuração recomendada de authservice do repositório público (em inglês). 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.

1. Acesse o pacote kpt:

   kpt pkg get https://github.com/GoogleCloudPlatform/asm-user-auth@release-1.0 .
   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. Uma implantação de produção não usa certificados autoassinados.

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 istio-system 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. Depois de gerar as chaves, coloque os dados da chave no mesmo formato:

   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
        }
     ]
   }
   

   cat ./samples/cookie_encryption_key.json
   {
     "keys":[
        {
           "kty":"oct",
           "kid":"key-0",
           "K":"YOUR_KEY",
           "useAfter": 1612813735
        }
     ]
   }
   

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

   Para encontrar o valor do rótulo REVISION, verifique a Implantação do Istiod.

   Importante: em um ambiente de produção, gere suas próprias chaves para preencher o arquivo JSON.

   kubectl create namespace asm-user-auth
   kubectl label namespace asm-user-auth istio.io/rev=REVISION --overwrite
   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.

1. Defina as variáveis oauth. O ID e a chave secreta do cliente são armazenados como segredos do Kubernetes, então usamos a Base64 para codificá-los.

   kpt cfg set pkg anthos.servicemesh.user-auth.oidc.clientID $(echo -n ${OIDC_CLIENT_ID} | base64 -w0)
   kpt cfg set pkg anthos.servicemesh.user-auth.oidc.clientSecret $(echo -n ${OIDC_CLIENT_SECRET} | base64 -w0)
   kpt cfg set pkg anthos.servicemesh.user-auth.oidc.issuerURI ${OIDC_ISSUER_URI}
   kpt cfg set pkg anthos.servicemesh.user-auth.oidc.redirectURIHost ${OIDC_REDIRECT_HOST}
   kpt cfg set pkg anthos.servicemesh.user-auth.oidc.redirectURIPath ${OIDC_REDIRECT_PATH}
   

2. 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. Ele contém os seguintes campos:

cat pkg/user_auth_config.yaml

apiVersion: security.anthos.io/v1beta1
kind: UserAuthConfig
metadata:
  name: user-auth-config
  namespace: asm-user-auth
spec:
  authentication:
    oidc:
      certificateAuthorityData: ""
      oauthCredentialsSecret:
        name: "oauth-secret"
        namespace: "asm-user-auth"
      issuerURI: "https://accounts.google.com"
      redirectURIHost: ""
      redirectURIPath: "/_gcp_asm/authenticate"

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 o aplicativo de amostra "Online Boutique" como exemplo.

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

O processo de instalação também cria um gateway do Istio para exibir o tráfego HTTPS usando o certificado TLS userauth-tls-cert que você criou acima. Esta é a configuração pkg/gateway.yaml.

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. Atualize o aplicativo "Online Boutique" para usar este gateway a fim de exibir tráfego HTTPS e use o encaminhamento de portas para acessá-lo localmente:

   kubectl apply -f./samples/boutique-route.yaml -n demo
   kubectl port-forward service/istio-ingressgateway 8443:443 -n istio-system
   

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

2. Verifique se o aplicativo de amostra "Online Boutique" pode ser acessado em https://localhost:8443/.

Verificar a autenticação do usuário

Os serviços do aplicativo "Online Boutique" agora exigem que os usuários finais façam login com a conta do Google deles.

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

2. Depois de fazer login, clique em Próximo e verifique se você é redirecionado para a página inicial do "Online Boutique".

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/rctoken-authz.yaml
   

2. O arquivo rctoken-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: RequestAuthentication
   metadata:
    name: require-rc-token
    namespace: istio-system
   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
    namespace: istio-system
   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
   

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 tokenEndpoint e authorizationEndpoint configurados no CRD UserAuthConfig têm uma rota configurada em VirtualService. As etapas de instalação anteriores definem isso no asm-user-auth/userauth-oidc VirtualService.

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

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 SSL do domínio do servidor de autorização do OIDC.
authentication.oidc.clientSecret	Referências do Tsecret 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.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 endpoint onde "authservice" encerrará o fluxo 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, ele 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.
authentication.oidc.groupsClaim	Se o "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.
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.

Implantação de vários clusters

A autenticação de usuário do Anthos 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, precisam ser replicadas 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.

Perguntas frequentes

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

   Siga o processo de upgrade do Anthos Service Mesh e especifique o arquivo de sobreposição user-auth.yaml na linha de comando para install_asm.

2. Quantos recursos devemos provisionar para o authservice? E quantas solicitações por segundo ele pode 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 authservice para aumentar a escalabilidade horizontal.