Keycloak

Inventory › Keycloak gestiona el Keycloak con el que las aplicaciones inician sesión. No se copia nada en Horizon: cada página lee Keycloak en directo y cada cambio se guarda en Keycloak al momento. Los viewer leen, los operator modifican.

En Sora, Keycloak lo despliega FluxCD dentro del clúster, vacío. Todo lo que hay dentro (realms, clientes, usuarios, ...) se configura desde aquí.

Conexión

En Admin › Infrastructure › Keycloak se indica su dirección, el realm de administración (normalmente master) y el usuario y contraseña de un administrador. Con FluxCD, el administrador inicial está en el secret keycloak-initial-admin:

kubectl -n keycloak-system get secret keycloak-initial-admin -o jsonpath='{.data.username}' | base64 -d
kubectl -n keycloak-system get secret keycloak-initial-admin -o jsonpath='{.data.password}' | base64 -d

La contraseña se usa una única vez: Horizon crea su propio cliente confidencial (horizon-admin) con el rol admin, guarda solo su secret y a partir de entonces accede únicamente con él.

• Verify comprueba que Keycloak responde, que el cliente inicia sesión y que puede listar los realms.
• Renew secret genera un secret nuevo y lo guarda en el mismo paso.
• Recreate client vuelve a crear el cliente si se borró en Keycloak.
• El administrador por defecto se puede desactivar desde aquí, una vez el cliente de Horizon funciona.

Realms

La lista muestra cada realm con su estado y cuántos roles, clientes, personas y aplicaciones contiene. New realm crea uno nuevo, por defecto con las políticas de autenticación recomendadas.

En los ajustes de cada realm:

• Nombre visible y estado.
• Sus endpoints OpenID (configuración, issuer, authorization, token, userinfo, logout), cada uno con su botón de copiar.
• Las políticas de autenticación comparadas con el valor recomendado (contraseña de 30 caracteres con número y símbolo, protección contra fuerza bruta, OTP, passkeys, ...), aplicables una a una o todas juntas.
• El correo, con un botón para enviar una prueba.
• El tema, entre los instalados (como el tema moon que despliega FluxCD).

Roles, scopes, clientes y personas

• Roles y scopes: cada rol con cuántas personas lo tienen, y cada scope con el rol al que está asociado. Un scope nuevo crea por defecto un rol con su mismo nombre.
• Clientes: cada cliente usa uno de dos flujos: Authorization Code con PKCE (una persona desde el navegador, cliente público) o Client Credentials (un servicio, cliente confidencial). El secret de un cliente confidencial se puede copiar sin mostrarlo o regenerar.
• Personas: búsqueda, alta (nombre, apellidos y email), roles, acciones requeridas en el siguiente inicio de sesión y contraseñas generadas que se muestran una única vez.

Aplicaciones

Una aplicación describe en un manifiesto KeycloakApplication todo lo que necesita de un realm: clientes, roles, scopes, roles de cliente y, si hace falta, sus propias personas (por ejemplo, la de los tests de integración). El manifiesto vive en el repositorio de la aplicación.

apiVersion: horizon/v1
kind: KeycloakApplication
name: sachiko
displayName: Sachiko
version: 1.4.0

variables:
  - name: host
    description: Where Sachiko is served
    required: true

roles:
  - name: sachiko:viewer
  - name: sachiko:admin

scopes:
  - name: sachiko:viewer
    role: sachiko:viewer
  - name: sachiko:admin
    role: sachiko:admin

Importarla (desde Git o subiendo el fichero) son tres pasos: el manifiesto, los valores que pide y una revisión que muestra, antes de cambiar nada, cada elemento tal como quedará y qué le pasará (crear, adoptar, cambiar, mantener o eliminar).

• Volver a importar una versión superior actualiza la aplicación. Una versión inferior se rechaza.
• Cada aplicación muestra si Keycloak sigue teniendo lo que declara; Apply again restaura lo que se haya cambiado a mano.
• Remove borra de Keycloak todo lo que la aplicación tiene. Let go la olvida en Horizon y deja todo en Keycloak.

El contrato completo está en keycloak-application.md.