Auth como código: um YAML, todo ambiente

A maioria dos dashboards de auth são máquinas do tempo apontadas para uma era pior das operações: clica aqui, torce pra ter lembrado em qual ambiente você está, tira screenshot do resultado pro audit log. Drift entre staging e prod é o default. Onboardar um engenheiro novo é "deixa eu compartilhar minha tela."

Construímos a CLI antes de construir o dashboard exatamente por isso. O Authaz é configurado por um único arquivo YAML, aplicado com um comando, e protegido por um ETag para que dois engenheiros não atropelem as mudanças um do outro.

O schema é real

O YAML abaixo é o schema que o Authaz.Cli realmente valida. apiVersion: authaz/v1 e kind: Application são obrigatórios. A forma espelha manifests do Kubernetes de propósito — engenheiros já sabem ler isso.

apiVersion: authaz/v1
kind: Application
metadata:
  name: acme
  etag: "5f3a2b1c"
spec:
  authentication:
    providers:
      emailPassword:
        enabled: true
        minLength: 12
        rejectBreached: true
      magicLink:
        enabled: true
        codeType: numeric
        codeLength: 6
        codeExpiryMinutes: 15
      oauth:
        - provider: google
          scopes: [openid, profile, email]
    mfa:
      mode: required
      allowedMethods: [totp, webauthn]
      primaryMethod: totp
      gracePeriodDays: 7
      requireForAdmins: true
    session:
      timeoutMinutes: 480
      idleTimeoutMinutes: 30
      maxConcurrentSessions: 5
  branding:
    preset: professional

+ spec.authentication.providers.magicLink: enabled
~ spec.authentication.mfa.mode: optional → required
+ spec.authentication.mfa.allowedMethods: [totp, webauthn]
+ spec.authentication.mfa.requireForAdmins: true
~ spec.authentication.session.timeoutMinutes: 720 → 480
+ spec.authentication.providers.oauth[google]: enabled
~ spec.branding.preset: indigo → professional
 
7 change(s)
Apply these changes? y
 
✓ Updated application acme
ETag: 9c4e1a8b…
7 change(s) applied.

Por que isso importa na prática

Algumas propriedades caem direto do design e a gente gosta delas:

• Revisável. Mudanças de auth aparecem como diff em PR que o time de segurança consegue ler. Acabou o "quem foi que desligou MFA em staging."
• Reproduzível. authaz export faz round-trip do tenant ao vivo de volta pro YAML. Subir um ambiente novo é importar isso.
• Seguro contra concorrência. Todo apply é protegido por um ETag em metadata.etag. Se outra pessoa mudou o tenant desde o seu export, o apply rejeita até você reexportar — ou você passa --force e aceita as consequências.
• Validado localmente. authaz validate roda o schema completo e os range-checks (MFA grace 0–365 dias, code length 4–10, max sessions 1–100, etc.) sem nem chamar o servidor. Bom para CI.

Para onde isso vai

Estamos trabalhando no mesmo formato para Authorization (papéis RBAC, permissões, tuplas de relação do Zeratul) e um kind Tenant que cuida de conexões SAML, overrides de branding e quotas no mesmo arquivo. Mesmo authaz apply, mesmo diff renderer, mesma proteção por ETag.

Se você quer testar a CLI antes do release público, entre na lista de espera — quem entra cedo recebe os primeiros builds.