Versión 1.9

Configura la autenticación de usuario de Anthos Service Mesh

La autenticación de usuarios de Anthos 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 del token web JSON (JWT) de Istio.

Un caso práctico típico es cuando una organización usa Anthos Service Mesh para alojar una aplicación web a la que su equipo de trabajo puede acceder mediante 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 usuario de Anthos Service Mesh facilita la autenticación de usuarios con un flujo de acceso y consentimiento estándar de OpenID Connect (OIDC). Cuando el usuario se autentica, Anthos Service Mesh aplica 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 usuario de Anthos 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 lado del cliente del protocolo OIDC y habilita el acceso de los usuarios a las aplicaciones a través de un navegador, en el que los usuarios completan un flujo interactivo de autenticación y consentimiento para establecer una sesión de corta duración. authservice implementa protocolos estándar de la industria para integrarse con cualquier proveedor de identidad que pueda actuar como un 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 reenvía a la capa de autorización de Istio en la entrada. Este modelo proporciona control de acceso del perímetro para el tráfico en la malla. Si el usuario está autorizado 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 las otras 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 Anthos Service Mesh. Cuando se instala, authservice lee la configuración del extremo de OIDC y otras configuraciones asociadas definidas en el recurso personalizado UserAuth. El administrador puede usar las API de ExternalAuthorization de la malla de servicios de Anthos para configurar auth_server como un filtro en el Ingress.

Instala el servicio de autenticación de usuarios

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

Requisitos previos

Antes de comenzar, debes tener un clúster con Anthos Service Mesh instalado según las instrucciones en Instala Anthos Service Mesh. Además, debes tener una carga de trabajo existente para habilitar la autenticación del usuario o implementar la aplicación de muestra de Online Boutique .

Prepara la configuración del cliente de OIDC

Establece la configuración de tu cliente OIDC con los siguientes pasos. En esta guía, se usa Google como IDP, pero puedes usar cualquier IdP que admita la autenticación de OIDC.

  1. En Cloud Console, ve a API y servicios > Credenciales.

    Ir a Credenciales

  2. Ve a Crear credenciales y, luego, 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 el Tipo de aplicación como Aplicación web.
    • Configura el URI de redireccionamiento autorizado como https://localhost:8443/_gcp_anthos_callback.

    Luego, haga clic en Guardar.

  3. Además, guarda tu ID de cliente y tu secreto de cliente para usarlos más adelante:

    export OIDC_CLIENT_ID='<your-client-id>'
    export OIDC_CLIENT_SECRET='<your-client-secret>'
    export OIDC_ISSUER_URI='https://accounts.google.com'
    

Obtén los paquetes de kpt

Usa los siguientes pasos para instalar la configuración authservice recomendada del repositorio público. Con estos comandos, se recuperará el contenedor authservice más reciente y se lo iniciará como un Pod en el espacio de nombres asm-user-auth. También configurará la entrada para interceptar todas las solicitudes.

  1. Obtén el paquete kpt:

    kpt pkg get https://github.com/GoogleCloudPlatform/asm-user-auth@release-0.1 .
    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. Una implementación de producción no usaría certificados autofirmados.

  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 istio-system 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 funcionar correctamente. 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 cookie.

El segundo conjunto de claves es un par de clave 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 archivos adicionales pueden usar para validar el JWT.

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

  1. Después de generar tus claves, coloca los datos de clave en el mismo formato:

    cat ./samples/rctoken_signing_key.json
    {
      "keys":[
         {
            "kty":"RSA",
            "kid":"rsa-signing-key",
            "K":"YOUR_KEY", # k contains a Base64 encoded PEM format RSA signing key.
            "useAfter": 1612813735, # unix timestamp
         }
      ]
    }
    
    cat ./samples/cookie_encryption_key.json
    {
      "keys":[
         {
            "kty":"oct",
            "kid":"key-0",
            "K":"YOUR_KEY",
            "useAfter": 1612813735
         }
      ]
    }
    
  2. Crea el secreto de Kubernetes, que authservice se activará en su propio sistema de archivos.

    kubectl create namespace asm-user-auth
    kubectl label namespace asm-user-auth  istio-injection=enabled istio.io/rev=default --overwrite
    kubectl create secret generic secret-key  \
        --from-file="session_cookie.key"="./samples/cookie_encryption_key.json" \
        --from-file="rctoken.key"="./samples/rctoken_signing_key.json"  \
        --namespace=asm-user-auth
    

Implementa el servicio de autenticación de usuarios

Con los siguientes comandos, se crea el servicio de autenticación de usuario y la implementación en el espacio de nombres asm-user-auth.

  1. Configura las variables oauth:

    kpt cfg set pkg anthos.servicemesh.user-auth.oidc.clientID ${OIDC_CLIENT_ID}
    kpt cfg set pkg anthos.servicemesh.user-auth.oidc.clientSecret ${OIDC_CLIENT_SECRET}
    kpt cfg set pkg anthos.servicemesh.user-auth.oidc.issuerURI ${OIDC_ISSUER_URI}
    
  2. Aplica el paquete kpt:

    kubectl apply -f ./pkg/asm_user_auth_config_v1alpha1.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, y puedes actualizarlo para que cambie el comportamiento authservice y configurarlo con extremos para cualquier servidor de autorización de OIDC. Contiene los siguientes campos:

cat pkg/user_auth_config.yaml
apiVersion: security.anthos.io/v1alpha1
kind: UserAuthConfig
metadata:
  name: auth-config
  namespace: user-auth
spec:
  authentication:
  - oidc:
      clientID: "${OIDC_CLIENT_ID}"
      clientSecret: "${OIDC_CLIENT_SECRET}"
      issuerURI: "${OIDC_ISSUER_URI}"
      scopes: allatclaim,group
      groupsClaim: "groups"
      redirectURIHost: https://localhost:8443
      redirectURIPath: "/_gcp_anthos_callback"
  outputJWTAudience: "test_audience"

Consulta los detalles de 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 que finalices 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 usuarios con la aplicación de muestra Online Boutique a modo de ejemplo.

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

  1. Configura el MeshConfig para el proveedor ExternalAuthorization:

    kubectl edit configmap istio -n istio-system
    
  2. En la configuración de la malla, agrega el servicio de autenticación de usuarios como proveedor de autorización:

    data:
     mesh: |-
       defaultConfig:
         discoveryAddress: istiod.istio-system.svc:15012
       extensionProviders:
       - envoyExtAuthzGrpc:
           port: "10003"
           service: authservice.asm-user-auth.svc.cluster.local
         name: asm-userauth-grpc
    

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

    El proceso de instalación también crea una puerta de enlace de Istio para entregar tráfico HTTPS con el certificado TLS que creaste en pkg/gateway.yaml.

    apiVersion: networking.istio.io/v1beta1
    kind: Gateway
    metadata:
     name: userauth
     namespace: asm-user-auth
    spec:
     selector:
       istio: ingressgateway
     servers:
     - hosts:
       - '*'
       port:
         name: https
         number: 443
         protocol: HTTPS
       tls:
         mode: SIMPLE
         credentialName: userauth-tls-cert
    ---
    # This ensures the OIDC endpoint has at least some route defined.
    apiVersion: networking.istio.io/v1beta1
    kind: VirtualService
    metadata:
     name: userauth-oidc
     namespace: asm-user-auth
    spec:
     gateways:
     - userauth
     hosts:
     - '*'
     http:
     - match:
       - uri:
           prefix: /status
       - uri:
           prefix: /_gcp_anthos_callback
       name: user-auth-route
       route:
       - destination:
           host: authservice
           port:
             number: 10004
    
  3. Actualiza la aplicación de la boutique en línea para usar esta puerta de enlace a fin de entregar tráfico HTTPS y usa la redirección de puertos para acceder a la aplicación de manera local:

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

    La puerta de enlace de entrada del puerto 8443 se reenviará a localhost para permitir el acceso local a la aplicación.

  4. Verifique que se pueda acceder a la aplicación de muestra de Online Boutique en https://localhost:8443/.

Verifica la autenticación del usuario

Los servicios de aplicación de la boutique en línea ahora requieren que los usuarios finales accedan mediante sus cuentas de Google.

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

  2. Después de acceder, haz clic en Siguiente y verifica que te redireccione a la página principal de Online Boutique.

Configura políticas de autorización

Después de que finalices 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 complete el flujo, authservice generará 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/rctoken-authz.yaml
    
  2. El archivo rctoken-authz.yaml configura la puerta de enlace de entrada para validar el token RC que emite authservice y solo autoriza cuando el JWT contiene los campos deseados, como públicos y emisores.

    Consulte el siguiente ejemplo de política de autorización:

    apiVersion: security.istio.io/v1beta1
    kind: RequestAuthentication
    metadata:
     name: require-rc-token
     namespace: istio-system
    spec:
     selector:
       matchLabels:
         istio: ingressgateway
     jwtRules:
     - issuer: "authservice.asm-user-auth.svc.cluster.local"
       audiences:
       - "test_audience"
       jwksUri: "http://authservice.asm-user-auth.svc.cluster.local:10004/_gcp_user_auth/jwks"
       fromHeaders:
       - name: X-ASM-RCTOKEN
       forwardOriginalToken: true
    ---
    apiVersion: security.istio.io/v1beta1
    kind: AuthorizationPolicy
    metadata:
     name: require-rc-token
     namespace: istio-system
    spec:
     selector:
       matchLabels:
         istio: ingressgateway
     action: ALLOW
     rules:
     - when:
       - key: request.auth.claims[iss]
         values:
         - authservice.asm-user-auth.svc.cluster.local
       - key: request.auth.claims[aud]
         values:
         - test_audience
    

Define 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 realizar un uso en producción real, usa tu propio dominio, como example.com.

Además, asegúrate de que tokenEndpoint y authorizationEndpoint configurados en la CRD de UserAuthConfig tengan una ruta configurada en VirtualService. En los pasos de instalación anteriores, se establece esto en asm-user-auth/userauth-oidc VirtualService.

Administrar 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 comprender cómo funciona la rotación.

Ambas claves están en formato JSON. El campo useAfter especifica la marca de tiempo desde el momento en que se considerará que la clave está en uso. Durante una rotación de clave, debes incluir claves antiguas y nuevas en JSON. 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
      }
   ]
}

La malla de servicios de Anthos usa la clave simétrica para encriptar los datos de la sesión que se almacenan en cookies del navegador. Para garantizar la validez de las sesiones existentes, authservice intenta realizar la desencriptación con todas las claves en el conjunto de claves. Durante la rotación, el authservice usará la clave nueva para encriptar sesiones nuevas y continuará con la desencriptación de 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 la verificación de JWT. Es fundamental que los archivos adicionales reciban la clave pública nueva antes de que authservice comience a usar la nueva clave privada para firmar la RCToken. Para ello, authservice comienza a publicar la clave pública inmediatamente después de que se agrega la clave, pero espera una cantidad de tiempo significativa antes de comenzar a usarla para firmar RCToken.

Detalles de configuración de autenticación del usuario

En la siguiente tabla, se describe cada campo del 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 usados en el flujo de OIDC.
authentication.oidc.certificateAuthorityData Este es el certificado SSL del dominio del servidor de autorización de OIDC.
authentication.oidc.clientID El ID de cliente de OAuth que se usará para el flujo de autenticación de OIDC.
authentication.oidc.clientSecret El secreto de cliente de OAuth que se usará para el flujo de autenticación de OIDC.
authentication.oidc.issuerURI El URI que se usará como entidad emisora en el RCToken de salida.
authentication.oidc.redirectURIHost y authentication.oidc.redirectURIPath El extremo en el que “authservice” finalizará el flujo de OAuth. Debes registrar este URI como un URI de redireccionamiento autorizado en el servidor de autorización para authentication.oidc.clientID.
Además, este URI debe entregarse desde la misma malla de servicios y el ingreso en el que se habilita “authservice”.
authentication.oidc.scopes El alcance de OAuth que debe solicitarse en la solicitud de autenticación.
authentication.oidc.groupsClaim Si el IDid contiene una reclamación de grupo, usa este campo para indicar su nombre. Si se especifica, el servicio transfiere los datos de esta reclamación a la reclamación `groups` en el RCToken de salida.
authentication.outputJWTAudience El público del RCToken generado por “authservice”. Los archivos adicionales pueden validar el RCToken entrante con este valor de público.