Delimitando o Litmus com Segurança: RBAC e Raio de Impacto

Existem duas alavancas, RBAC e raio de impacto, e você puxa as duas. No RBAC: o Litmus vem com o litmus-admin, uma service account com escopo em todo o cluster, que é aceitável para um sandbox e errada para produção. Cada ChaosExperiment já declara exatamente os verbos e recursos que a sua falha precisa, então construa uma ServiceAccount de privilégio mínimo por experimento ou por namespace de time, usando um Role e um RoleBinding em vez de um ClusterRole sempre que a falha permitir. Rode o Litmus com escopo por namespace para que um blast não atravesse fronteiras entre tenants. No raio de impacto: o appns e o applabel do ChaosEngine restringem o conjunto de alvos, PODS_AFFECTED_PERC e KILL_COUNT limitam quantos pods são afetados de uma vez, e para falhas de node ou infraestrutura o NODE_LABEL cerca quais nodes podem ser tocados. Sequencie múltiplas falhas de forma serial em vez de paralela, para não acumular falhas que você não consegue raciocinar sobre. Depois, adicione camadas de segurança operacional por cima: rode o chaos em seu próprio namespace, defina resource quotas, anexe probes em modo Continuous que falham rápido e abortam a execução quando um SLO é violado, e ensaie tudo antes em staging. E conheça de cor o botão de emergência: defina engineState como stop ou delete o ChaosEngine, o que reverte o chaos em regime de melhor esforço e desmonta o runner. O argumento de venda para a segurança é simples. Uma service account de privilégio mínimo, escopo por namespace, um raio de impacto limitado e uma probe com auto-halt são um risco menor e conhecido comparado aos modos de falha desconhecidos que você já está entregando à produção às cegas.