Pular para o conteúdo principal

Autenticação e Exposição de Serviços

Esta página explica como configurar a autenticação e quais serviços devem ser expostos para fora do cluster.

Modos de autenticação​

A implantação do Marketplace suporta dois modos de autenticação:

  • disabled
  • oidc

Autenticação desabilitada​

Este é o modo padrão e o caminho mais simples de implantação.

Use:

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

Escolha esse modo quando:

  • o acesso já é restrito pelo perímetro de rede
  • o ambiente é destinado apenas a usuários internos da plataforma
  • você quer o caminho mais rápido de implantação

Autenticação OIDC​

Use OIDC quando o ambiente precisa autenticar usuários por meio do seu identity provider.

Configure:

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"

O backend valida os JWTs contra o issuer e resolve automaticamente o documento JWKS, a menos que você forneça um OIDC_JWKS_URL dedicado.

O frontend usa a mesma configuração de runtime e espera o callback de login em:

/auth/callback

Para o perfil de implantação do Marketplace, OIDC_GROUPS_CLAIM e OIDC_CURRENT_ORG_CLAIM não são necessários e podem ser omitidos, a menos que sua organização tenha uma necessidade específica de mapeamento de identidade.

Sobre o Audience do OIDC

Se o seu identity provider não exigir validação de audience, você pode deixar OIDC_AUDIENCE vazio. Se ele for definido, o backend fará a validação de forma estrita.

Quais serviços devem ser expostos​

Você não precisa expor todos os serviços do cluster.

Serviços que normalmente são expostos​

  • Frontend
  • API
  • Gateway, se o gateway embutido estiver habilitado e você quiser acesso direto ao endpoint OpenAI-compatible

Serviços que devem permanecer internos​

  • PostgreSQL
  • Valkey
  • Job de migração
  • tráfego interno entre serviços Kubernetes

Configuração de ingress​

Se você usar ingress, o chart espera:

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

Exemplo:

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 e acesso por navegador​

Se o frontend e a API estiverem em origens diferentes, defina ALLOWED_ORIGINS com a lista completa de origens permitidas:

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

Se o gateway embutido for exposto diretamente para navegadores, configure também o CORS do gateway:

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