Okta org as code

Não comecei a escrever Terraform para Okta porque gosto de HCL. Ninguém gosta de HCL. Comecei por uma pergunta que parece fácil e não é: essa regra de política de sign-on, a que isenta um grupo de MFA, quem aprovou, e quando?

Numa org gerenciada pelo console, a resposta honesta é dar de ombros. A maioria das orgs foi configurada à mão, por quem tinha Super Admin naquele trimestre. Ninguém anotou o porquê. Três anos depois a org é um sítio arqueológico, e quem sabia ler as camadas já foi embora.

O que o código realmente compra

O Terraform inverte a direção da verdade: o repositório Git vira a intenção declarada; a org, um artefato reconciliado contra ela. Toda mudança chega como diff, com autor e aprovador. Só isso já justifica o esforço. A parte interessante é o drift.

O state registra o que o Terraform acredita ter criado; a org viva, o que existe depois que admins mexeram. Rode terraform plan toda noite, não só no deploy, e ele vira um controle detectivo. -detailed-exitcode retorna 0 quando a org bate com o código, 2 quando algo driftou, 1 em erro. Um job noturno que alerta no exit code 2 responde o que a maioria dos times de segurança não consegue: alguém mudou política de identidade em produção por fora do change management ontem?

A armadilha que faz times desistirem

O modo de falha mais instrutivo nunca lança erro. O Okta mantém prioridades de regras numa sequência densa: 1, 2, 3, sem buracos. Declare prioridades que colidem ou deixam buracos e o Okta renumera em silêncio; o refresh seguinte lê números que não batem com o seu código, e o plan mostra um diff. Você faz apply, o Okta renumera, o diff volta. Para sempre.

A conclusão se escreve sozinha: Terraform não funciona com Okta. O time volta para o console, e a org fica meio gerenciada, pior do que antes. A correção: declare prioridades explícitas e contíguas, e não deixe regra não gerenciada dentro de política gerenciada.

Raio de explosão é o problema de design de verdade

Um terraform apply errado em produção pode trancar a empresa inteira do lado de fora. Apague um bloco okta_app_oauth e o Terraform destrói o app, incluindo o client_id; tudo o que tinha esse ID hardcoded quebra, e recriar não devolve o ID.

Projete para contenção: um state file por tenant, um Super Admin de break-glass fora do Terraform para nenhum apply te trancar da própria org, prevent_destroy nos apps de produção, e produção aplicando só plan recém-calculado contra o estado vivo, depois que um humano leu.

Uma última pergunta: quem pode fazer merge na branch dona da política de sign-on de produção, e esse grupo é diferente de quem tem Super Admin? Se for “as mesmas pessoas”, você mudou o console para o GitHub sem ganhar um controle.

Comece menor do que você imagina

O código responde a minha pergunta inicial como efeito colateral: o diff é a aprovação, o merge é o timestamp, o plan noturno mantém a resposta verdadeira às 3 da manhã.

Nesta semana, numa org de preview: importe uma política de sign-on com terraform import, mude uma regra à mão no console, rode o plan com -detailed-exitcode. Veja voltar 2. Um recurso importado e um script de doze linhas: a configuração mais sensível da sua org, se dedurando sozinha.