Configura la autenticación de usuarios de Cloud Service Mesh

Si tienes la TRAFFIC_DIRECTOR implementación del plano de control, Esta función solo es compatible con las listas de entidades permitidas. Comunícate 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 el navegador y el control de acceso a tus cargas de trabajo implementadas. Te permite integrarte con proveedores de identidad (IdP) existentes para la autenticación de usuarios y usa API de Istio y políticas de autorización para la administración de acceso. Es una alternativa fácil de usar a la autenticación de token web JSON (JWT) de Istio.

Un caso de uso típico es cuando una organización usa Cloud Service Mesh para alojar una para que su personal acceda a través de un navegador web. Además, la organización debe usar su proveedor de identidad existente para administrar las identidades del usuario. La autenticación de usuarios de Cloud Service Mesh facilita la autenticación mediante un flujo de acceso y consentimiento estándar de OpenID Connect (OIDC) basado en la Web. Cuando el usuario se autentica, Cloud Service Mesh aplica políticas de autorización de Istio y, cuando se realiza de forma correcta, 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 presenta un componente nuevo, authservice. Este componente se integra con la entrada basada en Envoy como un servicio de autorización externo que intercepta todas las solicitudes entrantes de autenticación. authservice implementa el protocolo OIDC del cliente y permite el acceso de los usuarios a las aplicaciones a través de un navegador, en el que los usuarios completan un flujo de consentimiento y autenticación interactivo para establecer una sesión de corta duración. authservice implementa protocolos estándar de la industria para integrarse en cualquier proveedor de identidad 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 se reenvía a la capa de autorización de Istio en la entrada. Este modelo proporciona control de acceso al perímetro para el tráfico en la malla. Si el usuario está autorizado a 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 las demás partes de la malla, como la entrada, las cargas de trabajo, el navegador del usuario y cualquier IdP existente.

Autenticación del usuario final

Los administradores pueden instalar authservice como un complemento en una instalación de Cloud Service Mesh. Cuando se instala, authservice lee la configuración del extremo de OIDC y otros parámetros de configuración asociados que se definen en el recurso personalizado de UserAuth. El administrador puede usar las APIs de ExternalAuthorization de la malla de servicios de Cloud para configurar auth_server como filtro en el objeto Ingress

Instala el servicio de autenticación de usuarios

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

Requisitos previos

Sigue los pasos que se indican en Instala herramientas dependientes y valida el clúster para hacer lo siguiente:
  • Si usas Cloud Service Mesh administrado en un clúster privado, asegúrate de que puede enviar tráfico de salida al IdP.

Adicionalmente, sigue estos pasos para asegurarte de cumplir con los requisitos previos.

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

Para instalar el servicio de autenticación de usuarios, debes personalizar Cloud Service Mesh para agregar un proveedor de autorización externo a nivel de la malla. Pasos dependen de si usas Cloud Service Mesh administrado o en el clúster.

Administrado

  1. Actualiza el ConfigMap incluir la autenticación de usuario de MeshConfig. En el siguiente comando, usa el mismo REVISION_LABEL que usaste cuando aprovisionaste Cloud Service Mesh administrado (como asm-managed, asm-managed-rapid o asm-managed-stable):

    kubectl edit configmap istio-REVISION_LABEL -n istio-system

  2. Agrega 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 inserción. Los pasos dependen de la implementación del plano de control.

    Administrado (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

    Administrado (Istiod)

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

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

    Si eres un usuario existente con el plano de control administrado de Istiod, haz lo siguiente: Recomendamos que uses la inyección predeterminada, pero la inyección basada en revisiones no es compatible. Sigue estas instrucciones:

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

    El resultado es similar a este:

    NAME                AGE
asm-managed-rapid   6d7h

    En el resultado, el valor en la columna NAME es la etiqueta de revisión que corresponde al canal de versiones 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 puerta de enlace 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 superposición de autenticación del usuario y actualízala si hay personalizaciones en la malla. Se recomienda mantener este archivo de superposición en tu control fuente.

    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. usar una secuencia de comandos proporcionada por Google para instalar Cloud Service Mesh con el usuario la superposición de autenticación. 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 kpt de autenticación de usuarios crean una AuthorizationPolicy para hacer referencia al proveedor de autorización externo que especifica 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 inserción.

    Recomendado: Ejecuta el siguiente comando para aplicar la etiqueta de inserció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 se admite la inyección basada en revisiones: Sigue estas instrucciones:

    1. Usa el siguiente comando para encontrar 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 a los espacios de nombres. En el siguiente comando, REVISION_LABEL es el valor de la etiqueta de revisión istiod que anotaste en el paso anterior.

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

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

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

Prepara la configuración del cliente de OIDC

Sigue estos pasos para establecer la configuración del cliente de OIDC. En esta guía, se usa Google como IdP, pero puedes usar cualquier IdP que admita la autenticación de OIDC.

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

    Ir a Credenciales

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

    • Configura Tipo de aplicación como Aplicación web.
    • Configura el URI de redireccionamiento autorizado como https://REDIRECT_HOST/REDIRECT_PATH. Por ejemplo, para localhost, puedes establecer el valor https://localhost:8443/_gcp_asm_authenticate.

    Luego, haga 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

Obtén los paquetes kpt

Usa los siguientes pasos para instalar la configuración de authservice recomendada del repositorio público. Con estos comandos, se recupera el contenedor authservice más reciente y se lo inicia como un Pod en el espacio de nombres asm-user-auth. También configura la entrada 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/

Configura el secreto y la URL de redireccionamiento para la puerta de enlace de entrada

OAuth2 requiere una URL de redireccionamiento alojada en un extremo protegido por HTTPS. Estos comandos son, por ejemplo, para simplificar la configuración mediante la generación de un certificado autofirmado para la puerta de enlace 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 la puerta de enlace de entrada a fin de alojar tráfico HTTPS:

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

Aplica las claves de encriptación y firma

El authservice necesita dos conjuntos de claves para operar de forma correcta. La primera es una clave simétrica para la encriptación y desencriptación. Esta clave se usa para encriptar el estado de la sesión antes de configurarla como una cookie.

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

El paquete kpt de autenticación de usuarios contiene dos claves de muestra para una configuración rápida. Sin embargo, puedes usar tu sistema de administración de claves preferido para generar estas claves.

  1. Prepara la clave de encriptación de sesión con el siguiente formato o usa la muestra del pkg, que puedes ver mediante 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 la muestra del pkg, que puedes ver mediante 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 activará 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

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

Establece los valores necesarios para la configuración de autenticación de usuarios. El ID de cliente y el Secret se almacenan como Secrets de Kubernetes, por lo que usamos Base64 para codificarlos. Visita el repositorio público para ver todos los métodos set 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 la CRD UserAuthConfig para proporcionar la autenticación del usuario final. UserAuthConfig se puede configurar en el tiempo de ejecución. También puedes actualizarlo a fin de cambiar el comportamiento de authservice y configurarlo con extremos para cualquier servidor de autorización de OIDC.

Puedes ver el archivo mediante 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 del usuario para obtener descripciones detalladas de los campos user_auth_config.yaml.

Realiza tareas posteriores a la instalación

Las siguientes tareas son obligatorias después de completar los pasos de instalación anteriores.

Habilita la autenticación de usuarios para tus aplicaciones

En esta sección, se muestra cómo habilitar la autenticación de usuario mediante el uso de httpbin como ejemplo.

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

Después de instalar la puerta de enlace de Istio, configúrala para que entregue tráfico HTTPS con el certificado TLS userauth-tls-cert que creaste antes. A continuación, se muestra la configuración de pkg/gateway.yaml que acabas de esté instalado.

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 a fin de habilitar la inserción automática de istio-proxy para las implementaciones.

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

  2. Implementa 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 a fin de usar esta puerta de enlace para entregar tráfico HTTPS y usa la redirección de puertos a fin de acceder a la aplicación de manera 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 permitir el acceso local a la aplicación.

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

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

    Ejemplo 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

Verifica la autenticación del usuario

httpbin entrega dos rutas de acceso, /ip es de acceso público y /headers requiere que el usuario final acceda a través de su IdP configurado.

  1. Para verificar que puedes acceder a /ip directamente, visita https://localhost:8443/ip.

  2. Para verificar que veas la página de acceso de OIDC, visita https://localhost:8443/headers.

  3. Después de acceder, haz clic en Siguiente y verifica que te redireccione a la página /headers.

Configura políticas de autorización

Después de finalizar la configuración en los pasos anteriores, se redireccionará a cada usuario a través de un flujo de autenticación basado en la Web. Cuando se completa el flujo, authservice genera un RCToken en formato JWT, que se usa para transmitir la información del usuario autenticado.

  1. Agrega políticas de autorización de Istio a la entrada para garantizar que se realice una verificación de autorización de 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 de RC que emite el authservice y solo lo autoriza cuando el JWT contiene los campos deseados, como público y entidades emisoras.

    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.

Establece la configuración específica del entorno

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

Además, asegúrate de que certificateAuthorityData tenga el contenido del certificado raíz previsto. Por ejemplo, si al IdP se le otorgan los certificados raíz del sistema, puedes dejarlo vacío. Si hay un proxy HTTPS que finaliza la conexión HTTPS, debe establecerse en el certificado raíz del proxy.

Administra y rota claves

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

Ambas claves están en formato JSON. En el campo useAfter, se especifica la marca de tiempo desde que se considera que se usará la clave. Durante una rotación de claves, debes incluir claves antiguas y nuevas en el archivo 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 encriptar los datos de la sesión almacenados en las cookies del navegador. Para garantizar la validez de las sesiones existentes, authservice intenta desencriptar todas las claves en el conjunto de claves. Durante la rotación, authservice usará la clave nueva para encriptar las sesiones nuevas y seguirá intentando la desencriptación con las claves anteriores.

El par de claves pública/privada se usa para firmar RCToken. istiod transmite la clave pública a los sidecars para la verificación de JWT. Es fundamental que los sidecars reciban la clave pública nueva antes de que authservice comience a usar la clave privada nueva para firmar el RCToken. En este sentido, authservice comienza a publicar la clave pública de inmediato después de agregar la clave, pero espera un tiempo significativo antes de comenzar a usarla para firmar RCToken.

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

  1. Realiza rotaciones de claves frecuentes o a pedido, según lo necesites.
  2. En el formato JSON, incluye las claves actuales y nuevas. Las claves nuevas se deben asociar con una marca de tiempo en el futuro. Te recomendamos que especifiques una marca de tiempo con al menos un par de horas de anticipación de la hora actual.
  3. Supervisa y confirma que los servicios aún estén en buen estado después de usar la clave nueva. Espera al menos un día después de usar la clave nueva antes de continuar con el siguiente paso.
  4. Quita las claves anteriores de las entradas JSON. Ya no son necesarias.

Implementación de varios clústeres

La autenticación de usuarios de la malla de servicios de Cloud admite la implementación de varios clústeres. Debes implementar la autenticación del usuario en cada clúster como se describió antes. La configuración de autenticación del usuario, como el recurso personalizado UserAuth, el secreto de cliente de OIDC y las claves de encriptación, se deben replicar en cada clúster.

De forma predeterminada, la puerta de enlace de entrada realizará el balanceo de cargas de las solicitudes de autenticación en cualquiera de las instancias authservice. Puedes usar la regla de destino para configurar la puerta de enlace de entrada a fin de enviar solicitudes a authservice en el mismo clúster y solo conmutar 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 con otra configuración, esto debe configurarse en cada clúster.

Asignación de reclamaciones personalizadas

Para configurar la asignación de reclamaciones personalizadas, configura spec.authentication.oidc.attributeMapping para definir cualquier asignación del IDToken del proveedor de identidad original. La clave será el nombre de la reclamación en el RCToken y el valor es una expresión CEL sobre cómo analizar la reclamación de 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 configuraron:

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

Si la expresión CEL no analiza el valor de IDToken, ignorará el reclamo sin que falle el flujo de autenticación.

Actualizaciones de autenticación de usuarios

  1. Vuelve a instalar los paquetes user-auth, ya que contiene el objeto binario actualizado para la nueva versión del usuario:

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

  2. Guarda la configuración de 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 versión nueva.

Detalles de configuración de autenticación del usuario

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

Nombre del campo Descripción
authentication.oidc En esta sección, se conserva la configuración del extremo de OIDC y los parámetros que se usan en el flujo de OIDC.
authentication.oidc.certificateAuthorityData Este es el certificado raíz de SSL del dominio del servidor de autorización de OIDC o proxy HTTPS, si lo hay.
authentication.oidc.oauthCredentialsSecret Referencias de Secret al secreto de tipo opaco de Kubernetes que contiene client_id de OIDC de OAuth2 y client_secret en la carga útil de JSON.
authentication.oidc.issuerURI El URI que se usará como entidad emisora en el RCToken de salida.
authentication.oidc.proxy Servidor proxy al IdP de OIDC, si corresponde. Con el formato http://user:password@10.10.10.10:8888.
authentication.oidc.redirectURIHost El host que se usará para el URI de finalización de OAuth. Si dejas este campo vacío, se usará el host de la URL de destino y el URI de redireccionamiento se ensamblará de forma dinámica.
Este valor se puede usar cuando se desea 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 configurar en example.com. Esto permitirá establecer una sesión de autenticación de usuarios en example.com que se compartirá entre todos los subdominios. Nota: Si se entregan varios dominios desde la misma malla, example1.com y example2.com, no se puede usar la característica y se recomienda dejarla vacía.
authentication.oidc.redirectURIPath La ruta de acceso del extremo en la que authservice finalizará el flujo de OAuth. Debes registrar esta ruta de URI más el host como un URI de redireccionamiento autorizado en el servidor de autorización para authentication.oidc.clientID.
Además, este URI se debe entregar desde la misma malla de servicios y entrada en la que está habilitado authservice.
authentication.oidc.scopes El alcance de OAuth que se debe solicitar en la solicitud de autenticación. Lista separada por comas de identificadores que se usan para especificar qué privilegios de acceso se solicitan, además del permiso “openid”, p. ej. "groups,allatclaim".
authentication.oidc.groupsClaim Si el idtoken contiene una reclamación de grupo, usa este campo para indicar su nombre. Si se especifica, el servicio pasará los datos en esta reclamación a la reclamación groups en el RCToken de salida. Esta reclamación debe contener una lista separada por comas de strings, p. ej., ["group1", "group2"].
authentication.oidc.attributeMapping Contiene una o más asignaciones de reclamaciones de expresiones en CEL seguidas de idtoken. Todos los reclamos debe hacer referencia a assertion.X, se hace referencia a assertion al IDToken original, por ejemplo, aud_copy: assertion.aud.
authentication.outputJWTAudience El público del RCToken que genera authservice. Los archivos adicionales pueden validar el RCToken entrante en función de este valor de público.

Solución de problemas

  1. Accesibilidad de la red a IDP.

    Posible registro: error: TLS handshake failed..

    Para verificarlo, ejecuta curl desde el contenedor efímero conectado al istio-proxy para llamar Es el URI de la entidad emisora del IdP. Por ejemplo, consulta Recopila la malla de servicios de Cloud registros.

    Si no puedes conectarte, verifica las reglas de firewall o alguna otra configuración de red para el clúster.

  2. Certificado de CA raíz

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

    Asegúrate de que certificateAuthorityData contenga el Certificado de CA raíz correcto. Cuando no hay un proxy HTTPS que finalice el tráfico HTTPS, debe contener el Certificado de CA raíz para el IdP. En caso de que haya uno, debe contener el proxy.

  3. Configuración de la ruta de redireccionamiento.

    Observación posible: recibe la página de error 404 durante el flujo de autenticación de OIDC.

    La autorización de usuarios muestra el encabezado "Set-Cookie" sin usar el atributo path. De forma predeterminada, el navegador usa el directorio de la URL de solicitud como la ruta de la cookie (permiso de la cookie relacionada con la ruta). Por lo tanto, recomendamos no incluir “/” en la ruta de redireccionamiento, a menos que debas.

  4. El contenedor no puede recuperar jwksUri.

    En algunas situaciones, una restricción de sidecar podría provocar que no se recupere jwksUri. Si el espacio de nombres no está presente con un comodín (por ejemplo, ./* o istio-system/*), esto no funcionará. Debes agregar su espacio de nombres de forma manual en la salida un archivo adicional.

Preguntas frecuentes

  1. ¿Cómo actualizo Cloud Service Mesh con la autenticación de usuarios habilitada?

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

  2. ¿Cuántos recursos deberíamos aprovisionar para authservice? ¿Cuántas solicitudes por segundo puede manejar?

    De forma predeterminada, authservice se configura con CPU virtuales 2.0 y memoria de 256 Mi. Con esta configuración, authservice puede controlar 500 solicitudes por segundo. Para controlar una cantidad mayor de solicitudes, debes aprovisionar más CPU, lo que es aproximadamente proporcional a su capacidad de control de solicitudes. También puedes configurar varias réplicas del authservice para aumentar la escalabilidad horizontal.