Pular para o conteúdo

Segurança & privacidade

Como a CLI suya lida com credenciais, e como o Subaya isola seus dados.

SUBAYA_API_KEY é uma credencial que resolve diretamente para uma identidade na plataforma. Trate-a como qualquer outro segredo:

  • Nunca a faça commit em um repositório nem a embuta em uma imagem.
  • Injete-a por meio de variáveis de ambiente ou do seu cofre de segredos de CI/CD.
  • Emita e revogue chaves pelo console, e delimite-as à carga de trabalho que precisa delas.
Terminal window
export SUBAYA_API_KEY="sk_..."
suya auth whoami # confirm the identity the key resolves to

Quando mais de uma credencial está presente, o suya resolve nesta ordem:

  1. A flag global --token
  2. SUBAYA_API_KEY
  3. O token OAuth armazenado localmente

A flag --token tem precedência sobre tudo, então um token explícito na linha de comando sempre vence — útil para sobrescritas pontuais, mas evite colocar segredos de longa duração no histórico do shell.

O fluxo de navegador OAuth (suya auth login) armazena seu token localmente em ~/.config/suya/. Esse diretório guarda sua sessão ativa; proteja-o com permissões normais de sistema de arquivos. Para limpá-lo e revogar o token no servidor:

Terminal window
suya auth logout # log out and revoke the local token
suya auth status # confirm local auth state, no server call

A tenancy do Subaya é delimitada por org → workspace → projeto:

  • Uma organização é o tenant de nível superior — cobrança, membros e licenças ficam aqui.
  • Um workspace agrupa projetos dentro de uma org.
  • Um projeto é a unidade de trabalho.

Os dados são isolados entre organizações e entre workspaces: credenciais e consultas são delimitadas ao tenant ao qual pertencem, de modo que os designs, simulações e artefatos de uma org não são visíveis para outra. Veja Conceitos centrais para o modelo completo de tenancy.