Segurança e Hardening

Segredos

Cinco segredos determinam a segurança de um deployment. Gere cada um com openssl rand -hex 32.

BETTER_AUTH_SECRET precisa ser idêntica nos serviços app e realtime — eles compartilham sessões pelo banco de dados, e uma divergência faz o realtime rejeitar todo socket autenticado.

Onde guardá-los

Em ordem crescente de prontidão para produção:

1. --set na linha de comando — só para desenvolvimento. Os valores aparecem na saída de helm get values e no histórico do shell.
2. Um Secret do Kubernetes criado previamente — defina app.secrets.existingSecret.enabled: true e o nome do secret. Funciona com Sealed Secrets e SOPS. O secret é consumido por completo e precisa usar os nomes de chave padrão.
3. External Secrets Operator — sincronize a partir de Vault, AWS Secrets Manager, Azure Key Vault ou GCP Secret Manager. Recomendado.

Nos modos padrão e External Secrets, o chart grava todas as chaves sob app.env e realtime.env em um Secret gerenciado pelo chart e montado via envFrom, então nenhum valor fica embutido em uma spec de pod. (No modo existingSecret, o Secret pré-criado é a fonte da verdade e quaisquer valores de app.env que você ainda passar são renderizados inline — nesse modo, forneça tudo pelo Secret.) De qualquer forma, um segredo comitado no values.yaml é um segredo no seu histórico do git.

Fronteiras de rede

Ingress

Exponha apenas o app (3000) e o realtime (3002). Todo o resto — Postgres, Redis, o serviço de PII, os endpoints de cron — deve ser acessível somente de dentro do deployment.

Os endpoints de jobs em background sob /api/cron/*, /api/webhooks/poll/* e /api/schedules/execute são autenticados pelo CRON_SECRET, mas não há motivo para expô-los publicamente. Aponte o cron para o Service interno ao cluster.

NetworkPolicy

O chart traz uma policy opcional que isola o tráfego leste-oeste e bloqueia os endpoints de metadados da nuvem (169.254.169.254/32, 169.254.170.2/32) na saída — vale ativar, porque esses endpoints são o alvo padrão de escalonamento de SSRF.

networkPolicy:
  enabled: true

networkPolicy:
  ingressFrom:
    - namespaceSelector:
        matchLabels:
          kubernetes.io/metadata.name: ingress-nginx

A policy já permite saída HTTPS (443) para tudo, exceto os CIDRs de metadados, o que cobre APIs de provedores de modelos, APIs de integrações e endpoints de armazenamento de objetos na nuvem. Ela também permite o Postgres e o Redis empacotados, por seletor de pod.

O que ela não cobre é qualquer datastore que você rode fora do chart — um Postgres ou Redis gerenciado em uma porta diferente de 443. Adicione uma regra para cada:

networkPolicy:
  enabled: true
  egress:
    - to:
        - ipBlock:
            cidr: 10.0.0.0/16   # your VPC / managed-service subnet
      ports:
        - protocol: TCP
          port: 6379           # managed Redis
        - protocol: TCP
          port: 5432           # managed Postgres

Se manter listas de CIDR não valer o esforço, remova a restrição de portas:

networkPolicy:
  enabled: true
  allowExternalEgress: true

Os endpoints de metadados da nuvem continuam bloqueados nos dois casos. O padrão é false porque o chart do Studio é deliberadamente mais rígido que o padrão comum de charts, que permite saída sem restrições.

Pod Security Standards

Todas as workloads definem runAsNonRoot, removem todas as capabilities do Linux, desabilitam escalonamento de privilégios e usam seccompProfile: RuntimeDefault — os quatro controles exigidos pelo perfil restricted. Rotule o namespace para aplicá-lo:

kubectl label namespace studio pod-security.kubernetes.io/enforce=restricted

readOnlyRootFilesystem não é definido por padrão: Postgres e Ollama precisam de um root gravável, e o container do app escreve no .next/cache do Next.js. É viável nos serviços genuinamente sem estado (realtime, pii, copilot) — defina <component>.securityContext.readOnlyRootFilesystem: true e monte um emptyDir em /tmp via extraVolumes / extraVolumeMounts.

Onde o código das pessoas roda

Workflows podem executar JavaScript e Python escritos por pessoas. Saiba qual sandbox você está usando antes de expor o Studio a autores não confiáveis.

Python, Shell, JavaScript com imports externos e blocks dependentes de ferramentas exigem um provedor de sandbox remoto. JavaScript sem import ou require continua rodando no isolate em processo quando nenhum provedor remoto está configurado.

Tetos de recursos para o caminho em processo:

A fronteira de SSRF

O Studio bloqueia requisições de saída de ferramentas de banco de dados e de conectores para endereços privados, reservados e de loopback. Isso impede que um workflow seja usado para escanear a sua rede interna.

Deployments auto-hospedados muitas vezes precisam, legitimamente, alcançar um banco interno pelo nome do serviço. Isso é opt-in:

ALLOW_PRIVATE_DATABASE_HOSTS=true

IP do cliente e headers encaminhados

Atrás de um load balancer, X-Forwarded-For é controlável pelo cliente. Defina AUTH_TRUSTED_PROXIES com os endereços reais dos seus proxies para que o Better Auth resolva o IP real do cliente, e TRUSTED_ORIGINS se as pessoas acessam o Studio por mais de uma origem. Os dois estão cobertos em Autenticação.

Restringindo quem pode usar a instância

Listas de permissão e de bloqueio para cadastro, controles de login social, SSO e a saída de emergência DISABLE_AUTH estão todos cobertos em Autenticação. O resumo relevante para segurança: restrinja o cadastro antes de expor a instância, e nunca defina DISABLE_AUTH=true atrás de um ingress voltado para a internet.

Redação de PII

O serviço opcional baseado em Presidio dá suporte ao block Guardrails PII e, quando ativado, à redação automática de PII dos logs de workflow:

pii:
  enabled: true

app:
  env:
    PII_REDACTION: "true"
    INTERNAL_API_BASE_URL: "http://studio-app.studio.svc.cluster.local:3000"

INTERNAL_API_BASE_URL precisa ser a URL do Service interno ao cluster. O caminho de redação chama a própria API do app, e uma URL pública de ingress normalmente não é alcançável por hairpin de dentro do cluster. Sem um valor alcançável, o caminho falha de forma fechada — os campos afetados são substituídos por [REDACTION_FAILED] em vez de vazarem, mas a redação não roda de fato.

O serviço embute cerca de 2,2 GB de modelos spaCy, então a primeira inicialização leva por volta de três minutos e ele precisa de pelo menos 4 GB de memória.

Checklist pré-lançamento

• Todos os cinco segredos gerados do zero, guardados em um gerenciador de segredos e com a ENCRYPTION_KEY em backup separado
• BETTER_AUTH_SECRET idêntica no app e no realtime
• Imagens fixadas em uma tag ou digest explícito no app, no realtime e nas migrations
• TLS terminando no ingress; HTTP redirecionado ou desabilitado
• NEXT_PUBLIC_APP_URL e BETTER_AUTH_URL apontando para a origem pública real
• AUTH_TRUSTED_PROXIES definido se estiver atrás de um load balancer
• Cadastro restrito (DISABLE_REGISTRATION ou ALLOWED_LOGIN_DOMAINS)
• DISABLE_AUTH não definido
• NetworkPolicy ativada e ingressFrom restrito ao ingress controller
• Namespace rotulado com pod-security.kubernetes.io/enforce=restricted
• Buckets de armazenamento de objetos privados, com CORS limitado à sua origem do Studio
• Banco de dados acessível apenas de dentro do deployment; TLS obrigatório (sslMode: require)
• Backups configurados e uma restauração ensaiada
• Estratégia de sandbox definida para código escrito por pessoas