Ir al contenido principal

Autenticación y Exposición de Servicios

Esta página explica cómo configurar la autenticación y qué servicios deben exponerse fuera del clúster.

Modos de autenticación​

El despliegue de Marketplace soporta dos modos de autenticación:

  • disabled
  • oidc

Autenticación deshabilitada​

Este es el modo por defecto y el camino de despliegue más simple.

Usa:

runtime:
  commonEnv:
    AUTH_MODE: "disabled"
    AUTH_DISABLED: "true"

Elige este modo cuando:

  • el acceso ya está restringido por el perímetro de red
  • el entorno está destinado solo a usuarios internos de la plataforma
  • quieres el camino de despliegue más rápido

Autenticación OIDC​

Usa OIDC cuando el entorno necesita autenticar usuarios a través de tu identity provider.

Configura:

runtime:
  commonEnv:
    AUTH_MODE: "oidc"
    AUTH_DISABLED: "false"
    OIDC_ISSUER_URL: "https://id.example.com/realms/engineering"
    OIDC_AUDIENCE: "smart-engineering"
    OIDC_CLIENT_ID: "smart-engineering-ui"
    OIDC_SCOPE: "openid profile email"
    OIDC_EMAIL_CLAIM: "email"
    OIDC_NAME_CLAIM: "name"
    OIDC_USERNAME_CLAIM: "preferred_username"
    OIDC_POST_LOGOUT_REDIRECT_URI: "https://smart-eng.example.com/login"

El backend valida los JWTs contra el issuer y resuelve automáticamente el documento JWKS, a menos que proporciones un OIDC_JWKS_URL específico.

El frontend usa la misma configuración de runtime y espera el callback de login en:

/auth/callback

Para el perfil de despliegue de Marketplace, OIDC_GROUPS_CLAIM y OIDC_CURRENT_ORG_CLAIM no son necesarios y pueden omitirse, salvo que tu organización tenga un requisito específico de mapeo de identidad.

Sobre el Audience de OIDC

Si tu identity provider no requiere validación de audience, puedes dejar OIDC_AUDIENCE vacío. Si se define, el backend lo validará de forma estricta.

Qué servicios deben exponerse​

No necesitas exponer todos los servicios del clúster.

Servicios que normalmente se exponen​

  • Frontend
  • API
  • Gateway, si el gateway embebido está habilitado y quieres acceso directo al endpoint OpenAI-compatible

Servicios que deben permanecer internos​

  • PostgreSQL
  • Valkey
  • Job de migración
  • tráfico interno entre servicios Kubernetes

Configuración de ingress​

Si usas ingress, el chart espera:

  • ingress.frontendHost
  • ingress.apiHost
  • ingress.gatewayHost cuando gateway.enabled=true

Ejemplo:

ingress:
  enabled: true
  className: nginx
  frontendHost: smart-eng.example.com
  apiHost: api.smart-eng.example.com
  gatewayHost: gateway.smart-eng.example.com
  tls:
    - hosts:
        - smart-eng.example.com
        - api.smart-eng.example.com
        - gateway.smart-eng.example.com
      secretName: smart-eng-tls

CORS y acceso desde el navegador​

Si el frontend y la API usan orígenes distintos, define ALLOWED_ORIGINS con la lista completa de orígenes permitidos:

runtime:
  commonEnv:
    ALLOWED_ORIGINS: "https://smart-eng.example.com,https://api.smart-eng.example.com"

Si el gateway embebido se expone directamente a navegadores, configura también su CORS:

gateway:
  env:
    CORS_ALLOW_ORIGINS: "https://smart-eng.example.com"