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

Se tiver a TRAFFIC_DIRECTOR implementação do plano de controlo, esta funcionalidade só é suportada pela lista de autorizações. Contacte o apoio técnico para pedir que esta funcionalidade seja adicionada à lista de autorizações da sua organização

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 a sua força de trabalho aceder 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 se autentica, o Cloud Service Mesh aplica as políticas de autorização do Istio e, após a autorização bem-sucedida, transmite a identidade aos 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.

Além disso, certifique-se de que cumpre os pré-requisitos através dos seguintes passos.

Personalize a sobreposição de autenticação do utilizador de instalação

Para instalar o serviço de autenticação de utilizadores, tem de personalizar a instalação do Cloud Service Mesh para adicionar um fornecedor de autorização externo ao nível da malha. Os passos necessários dependem de estar a usar o Cloud Service Mesh gerido ou no cluster.

Gerido

  1. Atualize o ConfigMap para incluir o MeshConfig de autenticação do utilizador. 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 seguinte texto no campo mesh em MeshConfig:

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

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

    kubectl create namespace asm-user-auth

  4. Ative o espaço de nomes para injeção. Os passos dependem da sua implementação do plano de controlo.

    Gerido (TD)

    Aplique a etiqueta de injeção predefinida ao espaço de nomes:

    kubectl label namespace asm-user-auth \
    istio.io/rev- istio-injection=enabled --overwrite

    Gerido (Istiod)

    Recomendado: execute o seguinte comando para aplicar a etiqueta de injeção predefinida ao espaço de nomes:

    ```sh
kubectl label namespace asm-user-auth \
    istio.io/rev- istio-injection=enabled --overwrite
```

    Se for um utilizador existente com o plano de controlo do Istiod gerido: recomendamos que use a injeção predefinida, mas a injeção baseada em revisões é suportada. Siga as instruções abaixo:

    1. Execute o seguinte comando para localizar os canais de lançamento disponíveis:
    kubectl -n istio-system get controlplanerevision

    O resultado é semelhante ao seguinte:

    NAME                AGE
asm-managed-rapid   6d7h

    Na saída, o valor na coluna NAME é a etiqueta de revisão que corresponde ao canal de lançamento disponível para a versão do Cloud Service Mesh.

    1. Aplique a etiqueta de revisão ao espaço de nomes:

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

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

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 o espaço de nomes asm-user-auth.

    kubectl create namespace asm-user-auth

  4. Ative o espaço de nomes para injeção.

    Recomendado: execute o seguinte comando para aplicar a etiqueta de injeção predefinida ao espaço de nomes:

      kubectl label namespace asm-user-auth \
      istio.io/rev- istio-injection=enabled --overwrite

    Recomendamos que use a injeção predefinida, mas a injeção baseada em revisões é suportada: siga estas instruções:

    1. Use o seguinte comando para localizar a etiqueta 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 a etiqueta de revisão ao espaço de nomes. No comando seguinte, REVISION_LABEL é o valor da etiqueta de revisão istiod que anotou no passo anterior.

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

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

Receba os pacotes kpt

Siga os passos seguintes para instalar a configuração authservicerecomendada a partir do repositório público. Estes comandos obtêm o contentor authservice mais recente e iniciam-no como um pod no espaço de nomes asm-user-auth. Também configura a entrada para intercetar todos os pedidos.

Obtenha o pacote kpt:

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

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_KEY",
        "useAfter": 1612813735
     }
  ]
}

    Pode gerar 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 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_KEY",  # k contains a Base64 encoded PEM format RSA signing key.
        "useAfter": 1612813735  # unix timestamp
     }
  ]
}

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

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

  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 do utilizador 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.

Configure identificadores de pedidos de API

Os identificadores de pedidos de API são um conjunto de expressões do Idioma de expressão comum (IEC) usadas pela autenticação de utilizadores da Cloud Service Mesh para identificar pedidos de API. Ao definir estes identificadores, permite que a autenticação de utilizadores da Cloud Service Mesh processe semanticamente as falhas de autenticação de pedidos de API.

Especificamente, quando fornece expressões CEL que identificam os seus pedidos de API, permite que a autenticação de utilizadores da Cloud Service Mesh falhe em pedidos de API não autenticados com um código de estado 401-Unauthorized. Isto é fundamental para clientes como as ICs e as contas de serviço, que esperam este código de estado para pedidos de API não autenticados.

Sem identificadores de pedidos de API, a autenticação de utilizadores da Cloud Service Mesh vai redirecionar todos os pedidos não autenticados para o fornecedor OpenID Connect (OIDC) configurado, devolvendo um código de estado 302-Found. Geralmente, este comportamento de redirecionamento não é desejável para pedidos de API, que esperam um erro 401-Unauthorized em caso de falha.

Para definir os identificadores de pedidos da API, adicione uma secção apiRequestIdentifier ao seu UserAuthConfig CR. Isto permite adicionar várias expressões CEL. Se forem fornecidas várias expressões CEL, um pedido é considerado um pedido API se corresponder a, pelo menos, uma delas.

O exemplo seguinte mostra como designar como um pedido de API: qualquer pedido que contenha o cabeçalho example-api-header, qualquer pedido direcionado para o anfitrião api.example.com ou qualquer pedido que segmente um caminho em /v1/api/.

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}
  apiRequestIdentifier: 
    name: "api-request-identifiers"
    expressions: 
    - "'example-api-header' in http_request.headers"
    - "http_request.host == api.example.com"
    - "matches(http_request.path, '/v1/api/(.*)')"
    # other expressions go here

As expressões CEL de autenticação de utilizadores do Cloud Service Mesh podem ser criadas a partir dos seguintes campos:

  1. http_request.headers: um mapa dos cabeçalhos do pedido HTTP, em que as chaves são strings em minúsculas e os valores são vetores de strings.

    Use este campo na sua expressão de IEC para designar pedidos com cabeçalhos específicos como pedidos de API.

  2. http_request.host: o anfitrião do URL HTTP pedido (por exemplo, api.example.com).

    Use este campo na sua expressão CEL para designar pedidos a anfitriões específicos como pedidos de API.

  3. http_request.path: O caminho do URL HTTP pedido (por exemplo, /example-api-path). Começa sempre por "/" e não contém o componente de consulta do URL de pedido.

    Use este campo na sua expressão CEL para designar pedidos com caminhos específicos como pedidos de API.

A secção seguinte mostra exemplos de expressões CEL que verificam e fazem corresponder partes destes campos para informar a autenticação de utilizadores do Cloud Service Mesh sobre como determinar que pedidos são pedidos de API.

Exemplos de expressões

Corresponde a todos os pedidos que contêm o cabeçalho X-API-Key:

"'x-api-key' in http_request.headers"

Corresponde a todos os pedidos com o cabeçalho X-API-Key definido para um valor específico:

"'x-api-key' in http_request.headers && http_request.headers['x-api-key'].values == ['example-value ']"

Corresponde a todos os pedidos ao anfitrião api.example.com:

"http_request.host == api.example.com"

Fazer corresponder todos os pedidos ao caminho /api/query:

"http_request.path == /api/query"

Corresponde a todos os pedidos a qualquer caminho em /api/:

"matches(http_request.path, '/api/(.*)')"

Executar tarefas pós-instalação

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

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

Esta secção demonstra como ativar a autenticação de utilizadores usando o httpbin como exemplo.

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 de utilizadores 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 a regra de destino para configurar o gateway de entrada de forma 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 efémero anexado ao istio-proxy para chamar o URI do emissor do IDP. Por exemplo, consulte o artigo Recolher registos do Cloud Service Mesh.

    Se não conseguir estabelecer ligação, verifique as regras da firewall ou outras configurações de rede do 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?

    Siga o processo de atualização da malha de serviços na nuvem e especifique o ficheiro de sobreposição adicionando --custom_overlay user-auth-overlay.yaml na linha de comandos para asmcli install.

  2. Quantos recursos devemos 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.