Este tema describe cómo usar una instancia de Keycloak autoalojada como proveedor de identidades (IdP) para habilitar el inicio de sesión único en las aplicaciones de su service mesh. Al configurar un Custom Authorization Service en ASM, puede utilizar el protocolo OIDC para delegar la autenticación y la autorización a Keycloak. Esto elimina la necesidad de que cada aplicación implemente su propia lógica de seguridad. Una vez autorizada correctamente la solicitud, se reenvía a la aplicación junto con la información del usuario proveniente de Keycloak.
Requisitos previos
Se creó una instancia de ASM. Para obtener más información, consulte Create an ASM instance.
Se creó un clúster administrado de ACK. Para obtener más información, consulte Create an ACK managed cluster.
Habilitó la inyección automática de sidecar para el namespace
default. Para obtener más información, consulte Enable automatic sidecar injection.
Conceptos
|
Concepto |
Descripción |
|
IdP |
Un proveedor de identidades (IdP) es un servicio que crea, mantiene y gestiona las identidades de los usuarios, además de proporcionar servicios de autenticación. Por ejemplo, cuando utiliza una cuenta de Google para iniciar sesión en una aplicación de terceros, Google actúa como el IdP. |
|
OIDC |
OpenID Connect (OIDC) es un protocolo de autenticación construido sobre el framework OAuth 2.0. Para obtener más información, consulte OpenID Connect. |
|
Scope |
En OIDC, los scopes especifican qué atributos del usuario (como el correo electrónico o la información del perfil) puede acceder una aplicación. Durante la autenticación, el IdP puede solicitar al usuario que otorgue permiso para que la aplicación acceda a scopes específicos de sus datos. |
Procedimiento
Paso 1: Desplegar la aplicación de demostración y Keycloak
-
Utilice el siguiente manifiesto YAML para desplegar la aplicación httpbin en el namespace
defaultde su clúster administrado de ACK. Ejecute el comandokubectl apply -n default -f xxx.yaml. -
Utilice el siguiente manifiesto YAML para desplegar la aplicación Keycloak en el namespace
defaultde su clúster administrado de ACK. Ejecute el comandokubectl apply -n default -f xxx.yaml.
Paso 2: Exponer la aplicación y Keycloak mediante una puerta de enlace
En este ejemplo, se accede a la aplicación de demostración mediante HTTPS (puerto 443) y a la consola de Keycloak mediante HTTP (puerto 80).
Cree un certificado para el servicio HTTPS y asígnele el nombre
myexample-credential. Para obtener más información, consulte Enable Secure HTTPS Services by Using an ASM Ingress Gateway.-
Utilice el siguiente YAML para crear un Gateway y un VirtualService en el clúster de ASM, con el fin de exponer Keycloak a la red pública.
-
En la consola de ASM, configure el Gateway para la instancia de ASM correspondiente. Para obtener más información, consulte Manage gateway rules.
-
Aplique el siguiente VirtualService a la instancia de ASM. Para obtener más información, consulte Manage virtual services.
-
En su navegador, vaya a http://${ASM_INGRESS_GATEWAY_ADDRESS} para acceder a la aplicación Keycloak.
Haga clic en Administration Console e inicie sesión con las credenciales de administrador que configuró durante el despliegue de Keycloak.
Paso 3: Configurar Keycloak
En el panel de navegación izquierdo de Keycloak, seleccione Master en la lista desplegable y haga clic en Create Realm.
En la página de configuración del nuevo realm, cree un cliente. En la pestaña General Settings, establezca Client type en OpenID Connect y Client ID en oauth2proxy. En la pestaña Capability config, habilite Client authentication, deshabilite Authorization y, en la sección Authentication flow, seleccione únicamente las casillas Standard flow y Direct access grants.
Cree un usuario en el realm. Establezca Username en asm-test y habilite Email verified. A continuación, haga clic en Save.
En la página User details, haga clic en la pestaña Credentials.
Establezca una contraseña para el usuario. Configure Temporary en Off y haga clic en Save.
Cree un rol de realm. Establezca Role name en test-role y haga clic en Save.
En la página User details, seleccione la pestaña Role mapping.
En la página Role mapping, haga clic en Assign role. Asigne el rol
test-roleal usuario.Cree un client scope. Establezca Name en test_scope y Protocol en OpenID Connect. Habilite Display on consent screen y Include in token scope. Luego, haga clic en Save.
En la página Client Scope, haga clic en la pestaña Mappers y agregue un mapper. Establezca Mapper type en Audience y Name en test-mapper. Para Included Client Audience, seleccione oauth2proxy y habilite Add to access token. Después, haga clic en Save.
Haga clic en la pestaña Scope, seleccione la casilla junto al rol
test-roley luego haga clic en Assign.En la página de configuración del cliente, haga clic en la pestaña Client scopes y agregue el client scope
test_scopecomo scope predeterminado.Agregue las Valid redirect URIs para oauth2-proxy del clúster. En la pestaña Settings, dentro de la sección Access settings, introduzca
https://${ASM ingress gateway address}/oauth2/callbacken el campo Valid redirect URIs y haga clic en Save.
En este ejemplo, solo el servicio Keycloak utiliza el protocolo HTTP. Todos los demás servicios usan HTTPS. Por lo tanto, el formato de la redirect URI es https://${ASM_INGRESS_GATEWAY_ADDRESS}/oauth2/callback.
Keycloak ya está configurado. Registre la siguiente información:
El ID del nuevo realm: Test-oidc.
El ID de cliente creado en el realm: oauth2proxy.
El client secret ubicado en la subpestaña Credentials de la configuración del cliente.
Paso 4: Habilitar la autorización personalizada y el SSO con OIDC
Inicie sesión en la consola de ASM. En el panel de navegación izquierdo, elija .
En la página Mesh Management, haga clic en el nombre de la instancia de ASM. En el panel de navegación izquierdo, elija .
-
En la página External Authorization Service, haga clic en Register External Authorization Service y seleccione OIDC Authz and Authn Service. Configure los parámetros del OIDC Identity Authentication and Authorization Service y haga clic en Create.
En el panel Associate Custom Authorization Service, seleccione OIDC Identity Authentication and Authorization Service como tipo y configure los parámetros.
Introduzca la información del cliente OIDC que creó en Keycloak. Puede usar la puerta de enlace de ingreso de ASM como redirect URI para el inicio de sesión. Para obtener más información sobre el secreto de la cookie, consulte Generating a Cookie Secret.
IdP OIDC Issuer URL: http://${ASM_INGRESS_GATEWAY_ADDRESS}/realms/${REALM_NAME_IN_KEYCLOAK}.
ClientID y Client Secret: utilice los valores que registró en el paso anterior.
Scopes:
OpenIDes un scope obligatorio. También puede especificar otros scopes.
-
Cree un VirtualService con el siguiente YAML.
apiVersion: networking.istio.io/v1beta1 kind: VirtualService metadata: name: oauth2-vs namespace: istio-system spec: gateways: - ingressgateway hosts: - '*' http: - match: - uri: prefix: /oauth2 name: oauth2 route: - destination: host: asm-oauth2proxy-httpextauth-oidc.istio-system.svc.cluster.local port: number: 4180NotaReemplace el valor del campo
hosten la secciónroutepor el nombre del servicio de oauth2-proxy en el namespaceistio-systemde su clúster de ACK.Para evitar conflictos entre VirtualServices, asegúrese de que ningún otro VirtualService coincida con rutas que tengan el prefijo /oauth2.
Paso 5: Crear una política de autorización
En la página Mesh Management, haga clic en el nombre de la instancia de ASM. En el panel de navegación izquierdo, elija .
En la página AuthorizationPolicy, haga clic en Create from YAML.
-
En la página Create, seleccione un elemento en Namespaces y una plantilla en Scenario Template, configure el siguiente manifiesto YAML y haga clic en Create.
apiVersion: security.istio.io/v1beta1 kind: AuthorizationPolicy metadata: name: oidc namespace: istio-system spec: action: CUSTOM provider: name: httpextauth-oidc rules: - to: - operation: notPorts: - '80' selector: matchLabels: istio: ingressgatewayNotaEsta AuthorizationPolicy indica que todas las solicitudes dirigidas a puertos distintos del 80 requieren autorización.
En
provider.name, introduzca el nombre de su servicio de autorización personalizado asociado. Este nombre se encuentra en la lista de la página Custom Authorization Service.
Paso 6: Comprobar la integración
-
En su navegador, vaya a http://${ASM_INGRESS_GATEWAY_ADDRESS}:80.
Resultado esperado: aparece la página de inicio de sesión de OAuth2 Proxy con el botón Sign in with OpenID Connect, lo cual indica que el inicio de sesión único está habilitado.
-
Haga clic en Sign in with OpenID Connect. En la página de inicio de sesión de Keycloak, introduzca las credenciales del usuario de prueba creado en el paso 3 y haga clic en Log In.
Resultado esperado: tras iniciar sesión, se muestra la página de httpbin.org, que incluye categorías de API como HTTP Methods, Auth, Status codes y Request Inspection.
-
Haga clic en Request inspection y luego seleccione .
Resultado esperado: en la sección Server response, el cuerpo de la respuesta contiene la información de los encabezados de la solicitud, incluido el campo Authorization: Bearer {JWT}. Esto indica que la solicitud lleva el token JWT emitido por Keycloak.
-
Decodifique el token JWT del paso anterior (la cadena que sigue a
Bearer) mediante un depurador de JWT. Para obtener más información sobre estos depuradores, consulte JWT debugger.Resultado esperado: una vez decodificado correctamente el token, se observa que el algoritmo en HEADER es RS256 y que PAYLOAD contiene claims como realm_access (información del rol), preferred_username (nombre de usuario) y client_id (oauth2proxy). Esto confirma que ASM verificó el JWT y que este incluye la información del usuario almacenada en Keycloak.