Skip to main content

Authentication and Service Exposure

This page explains how to configure authentication and which services should be exposed outside the cluster.

Authentication modes​

The Marketplace deployment supports two authentication modes:

  • disabled
  • oidc

Disabled authentication​

This is the default and simplest deployment mode.

Use:

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

Choose this mode when:

  • access is already restricted by your network perimeter
  • the environment is intended for internal platform users only
  • you want the fastest deployment path

OIDC authentication​

Use OIDC when the environment must authenticate users through your identity provider.

Set:

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"

The backend validates JWTs against the issuer and resolves the JWKS document automatically unless you provide a dedicated OIDC_JWKS_URL.

The frontend uses the same runtime configuration and expects the login callback path:

/auth/callback

For the Marketplace deployment profile, OIDC_GROUPS_CLAIM and OIDC_CURRENT_ORG_CLAIM are not required and can be omitted unless your organization has a specific custom identity mapping requirement.

OIDC Audience

If your identity provider does not require audience validation, you can leave OIDC_AUDIENCE empty. If you set it, the backend validates it strictly.

Which services should be exposed​

You do not need to expose every service outside the cluster.

Services that are usually exposed​

  • Frontend
  • API
  • Gateway, if the bundled gateway is enabled and you want direct access to the OpenAI-compatible endpoint

Services that should remain internal​

  • PostgreSQL
  • Valkey
  • Migration job
  • internal Kubernetes service-to-service traffic

Ingress configuration​

If you use ingress, the chart expects:

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

Example:

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 and browser access​

If your frontend and API use different origins, set ALLOWED_ORIGINS to the full list of allowed browser origins:

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

If the bundled gateway is exposed directly to browsers, also set its CORS configuration:

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