Configurar la autenticación de usuarios de Cloud Service Mesh

Si tienes la TRAFFIC_DIRECTOR implementación del plano de control, esta función solo se admite en la lista de permitidos. Ponte en contacto con el equipo de Asistencia para solicitar acceso.

La autenticación de usuarios de Cloud Service Mesh es una solución integrada para la autenticación de usuarios finales basada en navegador y el control de acceso a tus cargas de trabajo implementadas. Te permite integrar proveedores de identidades para la autenticación de usuarios y usa las APIs y las políticas de autorización de Istio para gestionar el acceso. Es una alternativa sencilla a la autenticación con JSON Web Token (JWT) de Istio.

Un caso práctico habitual es cuando una organización usa Cloud Service Mesh para alojar una aplicación web a la que sus empleados pueden acceder a través de un navegador web. Además, la organización debe usar su proveedor de identidades para gestionar las identidades de los usuarios. La autenticación de usuarios de Cloud Service Mesh permite que los usuarios se autentiquen fácilmente mediante un flujo de inicio de sesión y consentimiento estándar basado en web de OpenID Connect (OIDC). Cuando el usuario se autentica, Cloud Service Mesh aplica las políticas de autorización de Istio y, si la autorización se realiza correctamente, transmite la identidad a las cargas de trabajo en un formato de credencial seguro.

Cómo funciona

La autenticación de usuarios de Cloud Service Mesh introduce un nuevo componente, authservice. Este componente se integra con el ingreso basado en Envoy como un servicio de autorización externo que intercepta todas las solicitudes entrantes para la autenticación. authservice implementa el lado del cliente del protocolo OIDC y permite que los usuarios accedan a las aplicaciones a través de un navegador, donde completan un flujo de autenticación y consentimiento interactivo para establecer una sesión de corta duración. authservice implementa protocolos estándar del sector para integrarse con cualquier proveedor de identidades que pueda actuar como servidor de autorización de OIDC. Cuando se autentica al usuario, la información principal se encapsula en un RCToken en formato JWT, firmado por authservice, que lo reenvía a la capa de autorización de Istio en el ingreso. Este modelo proporciona control de acceso perimetral para el tráfico que entra en la malla. Si el usuario tiene autorización para acceder a un recurso, este RCToken también se reenvía a los microservicios para obtener información principal y aplicar un control de acceso detallado.

En el siguiente diagrama se muestra la ubicación de authservice en la malla y cómo se relaciona con otras partes de la malla, como el ingreso, las cargas de trabajo, el navegador del usuario y cualquier IDP.

Autenticación de usuarios finales

Los administradores pueden instalar authservice como complemento sobre una instalación de Cloud Service Mesh. Una vez instalado, authservice lee la configuración del endpoint de OIDC y otros ajustes asociados definidos en el recurso personalizado UserAuth. El administrador puede usar las APIs de Cloud Service Mesh ExternalAuthorization para configurar auth_server como filtro en el tráfico de entrada.

Instalar el servicio de autenticación de usuarios

En los siguientes pasos se explica cómo configurar el authservice.

Requisitos previos

Sigue los pasos que se indican en Instalar herramientas dependientes y validar el clúster para:
  • Si usas Cloud Service Mesh gestionado en un clúster privado, asegúrate de que el clúster pueda enviar tráfico de salida al IdP.

Además, asegúrate de que cumples los requisitos previos siguiendo estos pasos.

Personalizar la superposición de autenticación de usuarios de la instalación

Para instalar el servicio de autenticación de usuarios, debes personalizar la instalación de Cloud Service Mesh para añadir un proveedor de autorización externo a nivel de malla. Los pasos necesarios dependen de si usas Cloud Service Mesh gestionado o en el clúster.

gestionados

  1. Actualiza el ConfigMap para incluir el MeshConfig de autenticación de usuarios. En el siguiente comando, usa el mismo REVISION_LABEL que usaste al aprovisionar Cloud Service Mesh gestionado (por ejemplo, asm-managed, asm-managed-rapid o asm-managed-stable):

    kubectl edit configmap istio-REVISION_LABEL -n istio-system

  2. Añade el siguiente texto en el campo mesh de MeshConfig:

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

  3. Crea el espacio de nombres asm-user-auth.

    kubectl create namespace asm-user-auth

  4. Habilita el espacio de nombres para la inyección. Los pasos dependen de la implementación del plano de control.

    Gestionado (TD)

    Aplica la etiqueta de inyección predeterminada al espacio de nombres:

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

    Gestionado (Istiod)

    Recomendación: Ejecuta el siguiente comando para aplicar la etiqueta de inyección predeterminada al espacio de nombres:

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

    Si ya eres usuario del plano de control de Istiod gestionado: Te recomendamos que utilices la inyección predeterminada, pero también se admite la inyección basada en revisiones. Sigue estas instrucciones:

    1. Ejecuta el siguiente comando para localizar los canales de lanzamiento disponibles:
    kubectl -n istio-system get controlplanerevision

    El resultado debería ser similar al siguiente:

    NAME                AGE
asm-managed-rapid   6d7h

    En el resultado, el valor de la columna NAME es la etiqueta de revisión que corresponde al canal de lanzamiento disponible para la versión de Cloud Service Mesh.

    1. Aplica la etiqueta de revisión al espacio de nombres:

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

  5. Instala la pasarela de Istio en el espacio de nombres asm-user-auth.

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

En el clúster

  1. Obtén el ejemplo de superposición de autenticación de usuario y actualízalo si hay alguna personalización en tu malla. Te recomendamos que mantengas este archivo de superposición en tu control de origen.

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

  2. Sigue las instrucciones para instalar Cloud Service Mesh con superposición para usar una secuencia de comandos proporcionada por Google que instale Cloud Service Mesh con la superposición de autenticación de usuario. Por ejemplo:

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

    Los paquetes de autenticación de usuarios kpt crean un AuthorizationPolicy para hacer referencia al proveedor de autorización externo especificado por pkg/ext-authz.yaml.

  3. Crea el espacio de nombres asm-user-auth.

    kubectl create namespace asm-user-auth

  4. Habilita el espacio de nombres para la inyección.

    Recomendación: Ejecuta el siguiente comando para aplicar la etiqueta de inyección predeterminada al espacio de nombres:

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

    Te recomendamos que uses la inyección predeterminada, pero también se admite la inyección basada en revisiones: Sigue estas instrucciones:

    1. Usa el siguiente comando para localizar la etiqueta de revisión en istiod:

      kubectl get deploy -n istio-system -l app=istiod -o \
  jsonpath={.items[*].metadata.labels.'istio\.io\/rev'}'{"\n"}'

    2. Aplica la etiqueta de revisión al espacio de nombres. En el siguiente comando, REVISION_LABEL es el valor de la etiqueta de revisión istiod que has anotado en el paso anterior.

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

  5. Instala la pasarela de Istio en el espacio de nombres asm-user-auth.

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

Preparar la configuración del cliente de OIDC

Para definir la configuración del cliente de OIDC, sigue estos pasos: En esta guía se usa Google como proveedor de identidades, pero puedes usar cualquier proveedor que admita la autenticación OIDC.

  1. En la Google Cloud consola, ve a APIs y servicios > Credenciales.

    Ir a Credenciales

  2. Ve a Crear credenciales y elige ID de cliente de OAuth. Si es necesario, define las opciones de la pantalla de consentimiento de OAuth y, a continuación, configura las siguientes opciones:

    • En Tipo de aplicación, selecciona Aplicación web.
    • Define URI de redirección autorizado como https://REDIRECT_HOST/REDIRECT_PATH. Por ejemplo, en el caso de localhost, puedes definirlo como https://localhost:8443/_gcp_asm_authenticate.

    A continuación, haz clic en Guardar.

  3. Además, guarda la configuración del cliente de OIDC para usarla más adelante.

    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

Obtener los paquetes de kpt

Sigue estos pasos para instalar la authserviceconfiguración recomendada del repositorio público. Estos comandos recuperan el contenedor authservice más reciente y lo inician como un pod en el espacio de nombres asm-user-auth. También configura el acceso para interceptar todas las solicitudes.

Obtén el paquete kpt:

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

Definir la URL de redirección y el secreto de la pasarela de entrada

OAuth2 requiere una URL de redirección alojada en un endpoint protegido con HTTPS. Estos comandos se utilizan a modo de ejemplo y simplifican la configuración generando un certificado autofirmado para la pasarela de entrada de Istio.

  1. Genera un certificado autofirmado:

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

  2. Crea un secreto para que la pasarela de entrada aloje el tráfico HTTPS:

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

Aplicar las claves de cifrado y firma

La authservice necesita dos conjuntos de claves para funcionar correctamente. La primera es una clave simétrica para cifrar y descifrar. Esta clave se usa para cifrar el estado de la sesión antes de definirlo como una cookie.

El segundo conjunto de claves es un par de claves pública y privada. Esta clave se usa para firmar la información del usuario autenticado en formato JWT como RCToken. La clave pública de este par se publica en un endpoint predefinido que los sidecars pueden usar para validar el JWT.

El paquete de autenticación de usuarios kpt contiene dos claves de ejemplo para una configuración rápida. Sin embargo, puedes usar el sistema de gestión de claves que prefieras para generar estas claves.

  1. Prepara la clave de cifrado de sesión con el siguiente formato o usa el ejemplo del paquete, que puedes ver con cat ./samples/cookie_encryption_key.json.

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

    Puedes generar una clave AES de prueba con el siguiente comando:

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

  2. Prepara la clave de firma de RCToken con el siguiente formato o usa el ejemplo del paquete, que puedes ver con 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
     }
  ]
}

    Puedes generar una clave privada RSA de 256 bits de prueba con el siguiente comando:

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

  3. Crea el secreto de Kubernetes, que authservice montará en su propio sistema de archivos.

    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

Implementar el servicio de autenticación de usuarios

Los siguientes comandos crean el servicio de autenticación de usuarios y la implementación en el espacio de nombres asm-user-auth.

Define los valores necesarios para la configuración de autenticación de usuario. El ID y el secreto de cliente se almacenan como secretos de Kubernetes, por lo que usamos Base64 para codificarlos. Visita el repositorio público para ver todos los setters disponibles.

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

Aplica el paquete 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

El authservice consume el CRD UserAuthConfig para proporcionar autenticación de usuario final. UserAuthConfig se puede configurar en el tiempo de ejecución y puedes actualizarlo para cambiar el comportamiento de authservice y configurarlo con endpoints para cualquier servidor de autorización de OIDC.

Puedes ver el archivo por cat pkg/user_auth_config.yaml, que contiene los siguientes 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}

Consulta los detalles de la configuración de autenticación de usuarios para ver descripciones detalladas de los campos de user_auth_config.yaml.

Realizar tareas posteriores a la instalación

Después de completar los pasos de instalación anteriores, debes realizar las siguientes tareas.

Habilitar la autenticación de usuarios en tus aplicaciones

En esta sección se muestra cómo habilitar la autenticación de usuarios. Para ello, se usa httpbin como ejemplo.

La autenticación de usuarios de Cloud Service Mesh usa una política de autorización de tipo CUSTOM para activar el flujo de OIDC.

Una vez que hayas instalado la pasarela de Istio, configúrala para que sirva tráfico HTTPS mediante el certificado TLS userauth-tls-cert que has creado anteriormente. A continuación se muestra la configuración de pkg/gateway.yaml que acabas 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. Etiqueta el espacio de nombres default para habilitar la inyección automática de istio-proxy en las implementaciones.

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

  2. Despliega httpbin en el espacio de nombres default.

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

  3. Actualiza httpbin para que use esta pasarela para servir tráfico HTTPS y usa el reenvío de puertos para acceder a la aplicación de forma local:

    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

    La puerta de enlace de entrada del puerto 8443 se reenviará a localhost para que la aplicación sea accesible de forma local.

  4. Implementa samples/rctoken-authz.yaml para habilitar RequestAuthentication y AuthorizationPolicy para verificar el RCToken de las solicitudes.

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

    Ejemplo de 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

Verificar la autenticación de usuarios

El httpbin sirve dos rutas: /ip es de acceso público y /headers requiere que el usuario final inicie sesión a través de su proveedor de identidades configurado.

  1. Comprueba que puedes acceder a /ip directamente visitando https://localhost:8443/ip.

  2. Comprueba que ves la página de inicio de sesión de OIDC visitando https://localhost:8443/headers.

  3. Después de iniciar sesión, haz clic en Siguiente y comprueba que se te redirige a la página /headers.

Configurar políticas de autorización

Una vez que hayas completado la configuración en los pasos anteriores, se redirigirá a cada usuario a través de un flujo de autenticación basado en la Web. Cuando se completa el flujo, el authservice generará un RCToken en formato JWT, que usará para transmitir la información del usuario autenticado.

  1. Añade políticas de autorización de Istio en el ingreso para asegurarte de que se realiza una comprobación de autorización para cada usuario autenticado:

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

  2. El archivo httpbin-authz.yaml configura la puerta de enlace de entrada para validar el token RC emitido por authservice y solo autoriza cuando el JWT contiene los campos deseados, como audiencias y emisores.

    Consulta la siguiente política de autorización de ejemplo:

    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.

Configurar ajustes específicos del entorno

En los pasos anteriores se usa localhost y un certificado HTTPS autofirmado para realizar una configuración rápida. Para usarlo en un entorno de producción real, utiliza tu propio dominio, como example.com.

Además, asegúrese de que certificateAuthorityData tiene el contenido del certificado raíz previsto. Por ejemplo, si el proveedor de identidades tiene los certificados raíz del sistema, puedes dejarlo vacío. Si hay un proxy HTTPS que finaliza la conexión HTTPS, debe configurarse con el certificado raíz del proxy.

Gestionar y rotar claves

authservice usa dos conjuntos de claves. Puedes rotar cada clave de forma independiente. Sin embargo, antes de rotar las claves, es importante que sepas cómo funciona la rotación.

Ambas claves están en formato JSON. El campo useAfter especifica la marca de tiempo desde la que se podrá usar la clave. Durante la rotación de una clave, debes incluir tanto la clave antigua como la nueva en el JSON. Por ejemplo, en el siguiente ejemplo, new-key solo se usará después de la marca de tiempo 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
      }
   ]
}

Cloud Service Mesh usa la clave simétrica para cifrar los datos de sesión que se almacenan en las cookies del navegador. Para asegurar la validez de las sesiones actuales, authservice intenta descifrar los datos con todas las claves del conjunto de claves. Cuando se rote, el authservice usará la nueva clave para cifrar las nuevas sesiones y seguirá intentando descifrar con las claves antiguas.

El par de claves pública/privada se usa para firmar RCToken. istiod transmite la clave pública a los sidecars para verificar el JWT. Es fundamental que los sidecars reciban la nueva clave pública antes de que authservice empiece a usar la nueva clave privada para firmar el RCToken. Para ello, authservice empieza a publicar la clave pública inmediatamente después de que se añada, pero espera un tiempo considerable antes de empezar a usarla para firmar RCToken.

En resumen, cuando realices rotaciones de claves, te recomendamos lo siguiente:

  1. Realiza rotaciones de claves periódicas o bajo demanda según sea necesario.
  2. En el formato JSON, incluye tanto la clave actual como la nueva. Las nuevas claves deben asociarse a una marca de tiempo futura. Te recomendamos que especifiques una marca de tiempo que sea al menos un par de horas posterior a la hora actual.
  3. Monitoriza los servicios y confirma que siguen funcionando correctamente después de que se haya empezado a usar la nueva clave. Espera al menos un día después de que se haya usado la nueva clave antes de pasar al siguiente paso.
  4. Elimina las claves antiguas de las entradas JSON. Ya no son necesarios.

Despliegue de varios clústeres

La autenticación de usuarios de Cloud Service Mesh admite implementaciones multiclúster. Debes desplegar la autenticación de usuario en cada clúster como se ha descrito anteriormente. La configuración de autenticación de usuario, como el recurso personalizado UserAuth, el secreto de cliente de OIDC y las claves de cifrado, debe replicarse en cada clúster.

De forma predeterminada, la puerta de enlace de entrada equilibrará la carga de las solicitudes de autenticación a cualquiera de las instancias de authservice. Puedes usar la regla de destino para configurar la puerta de enlace de entrada de forma que envíe solicitudes al authservice del mismo clúster y solo se produzca una conmutación por error a los authservice de otros clústeres.

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

Al igual que otras configuraciones, esta debe configurarse en cada clúster.

Asignación de reclamaciones personalizadas

Para configurar la asignación de reclamaciones personalizadas, configure spec.authentication.oidc.attributeMapping para definir las asignaciones del ID de proveedor de identidades original. La clave será el nombre de la reclamación en el RCToken y el valor será una expresión CEL sobre cómo analizar la reclamación del IDToken. Usa assertion para hacer referencia al IDToken.

Ejemplo:

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

En el RCToken, una reclamación anidada attributes contiene las reclamaciones que se han configurado:

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

Si la expresión CEL no puede analizar el valor de IDToken, ignorará la reclamación sin que se produzca un error en el flujo de autenticación.

Cambios a una versión superior de autenticación de usuario

  1. Vuelve a instalar los paquetes user-auth, ya que contienen el binario actualizado de la nueva versión user-auth:

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

  2. Guarda la configuración del cliente de 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. Implementa el servicio de autenticación de usuarios para actualizar a una nueva versión.

Detalles de la configuración de la autenticación de usuarios

En la siguiente tabla se describe cada campo de la CRD:

Nombre del campo Descripción
authentication.oidc Esta sección contiene la configuración del endpoint de OIDC y los parámetros utilizados en el flujo de OIDC.
authentication.oidc.certificateAuthorityData Este es el certificado raíz SSL del dominio del servidor de autorización de OIDC o del proxy HTTPS, si lo hay.
authentication.oidc.oauthCredentialsSecret Referencias secretas al secreto de tipo Opaque de Kubernetes que contiene client_id y client_secret de OAuth2 OIDC en la carga útil JSON.
authentication.oidc.issuerURI El URI que se debe usar como emisor en el RCToken de salida.
authentication.oidc.proxy Servidor proxy del proveedor de identidades de OIDC, si procede. Con el formato http://usuario:contraseña@10.10.10.10:8888.
authentication.oidc.redirectURIHost El host que se usará para el URI de finalización de OAuth. Si lo dejas vacío, se usará el host de la URL de destino y el URI de redirección se creará de forma dinámica.
Este valor se puede usar cuando se quiera una sesión de SSO de autenticación de usuario en un dominio de nivel superior. Por ejemplo, para habilitar el SSO entre profile.example.com/ y admin.example.com/, este valor se puede definir como example.com. De esta forma, se establecerá una sesión de autenticación de usuario en example.com que se compartirá entre todos los subdominios. Nota: Si se sirven varios dominios desde la misma malla (por ejemplo, example1.com y example2.com), no se puede usar la función y se recomienda dejar el campo vacío.
authentication.oidc.redirectURIPath La ruta del endpoint donde authservice finalizará el flujo de OAuth. Debes registrar esta ruta de URI más el host como URI de redirección autorizado en el servidor de autorización de authentication.oidc.clientID.
Además, este URI debe servirse desde la misma malla de servicios y entrada donde authservice esté habilitado.
authentication.oidc.scopes El ámbito de OAuth que se debe solicitar en la solicitud de autenticación. Lista de identificadores separados por comas que se usa para especificar qué privilegios de acceso se solicitan además del ámbito "openid". Por ejemplo: "groups,allatclaim".
authentication.oidc.groupsClaim Si el idtoken contiene una reclamación de grupos, usa este campo para indicar su nombre. Si se especifica, el servicio transferirá los datos de esta reclamación a la reclamación groups del RCToken de salida. Esta reclamación debe contener una lista de cadenas separadas por comas, por ejemplo: ["grupo1", "grupo2"].
authentication.oidc.attributeMapping Contiene una o varias asignaciones de reclamaciones de idtoken seguidas de expresiones CEL. Todas las reclamaciones deben hacer referencia a assertion.X. assertion hace referencia al ID de token original, por ejemplo, aud_copy: assertion.aud..
authentication.outputJWTAudience La audiencia del RCToken generado por authservice. Los archivos sidecar pueden validar el RCToken entrante con este valor de audiencia.

Solucionar problemas

  1. Accesibilidad de la red al proveedor de identidades.

    Registro posible: error: TLS handshake failed..

    Para verificarlo, ejecuta curl desde el contenedor efímero adjunto a istio-proxy para llamar al URI del emisor de IDP. Por ejemplo, consulta el artículo sobre cómo recoger registros de Cloud Service Mesh.

    Si no puedes conectarte, comprueba las reglas del cortafuegos u otras configuraciones de red del clúster.

  2. Certificado de AC raíz.

    Registro posible: error: The server's TLS certificate did not match expectations. o error: TLS handshake failed..

    Asegúrate de que certificateAuthorityData contiene el certificado de CA raíz correcto. Cuando no hay ningún proxy HTTPS que termine el tráfico HTTPS, este campo debe contener el certificado de CA raíz del proveedor de identidades. Si hay uno, este debe contener los del proxy.

  3. Configuración de la ruta de redirección.

    Posible observación: se recibe una página de error 404 durante el flujo de autenticación OIDC.

    La autenticación de usuario devuelve el encabezado "Set-Cookie" sin usar el atributo de ruta, por lo que, de forma predeterminada, el navegador usa el directorio de la URL de la solicitud como ruta de la cookie (el ámbito de la cookie relacionado con la ruta). Por lo tanto, te recomendamos que no incluyas "/" en la ruta de redirección, a menos que sea tu intención.

  4. El sidecar no puede obtener jwksUri.

    En algunos casos, una restricción de sidecar puede provocar un error al obtener jwksUri. Si el espacio de nombres no está presente y se usa un comodín (por ejemplo, ./* o istio-system/*), no funcionará. Debes añadir manualmente su espacio de nombres en el sidecar de salida.

Preguntas frecuentes

  1. ¿Cómo puedo actualizar Cloud Service Mesh con la autenticación de usuario habilitada?

    Sigue el proceso de actualización de Cloud Service Mesh y especifica el archivo de superposición añadiendo --custom_overlay user-auth-overlay.yaml en la línea de comandos a asmcli install.

  2. ¿Cuántos recursos debemos aprovisionar para la authservice? ¿Y cuántas solicitudes por segundo puede gestionar?

    De forma predeterminada, authservice se configura con 2, 0 vCPU y 256 Mi de memoria. Con esta configuración, authservice puede gestionar 500 solicitudes por segundo. Para gestionar mayores cantidades de solicitudes, debe aprovisionar más CPU, lo que es aproximadamente proporcional a su capacidad de gestión de solicitudes. También puedes configurar varias réplicas de authservice para aumentar la escalabilidad horizontal.