Colapso de Cotas no Service Control do Google Cloud

Incident Overview (Without Journalism)

Superficie institucional primaria: Distributed Systems Architecture.

Linhas de capacidade acionadas: Consistency and partition strategy design; Failure propagation control; Replica recovery and convergence patterns.

Mecanismo dominante de falha: falha de governanca de rollback/rollforward sob metadados de controle replicados globalmente.

Tier A (confirmed): o Google informou que em 12 de junho de 2025 multiplos produtos do Google Cloud, Google Workspace e Google Security Operations passaram a retornar 503 elevados porque requisicoes que atravessavam os planos de gerenciamento e controle de APIs do Google nao conseguiam concluir verificacoes de politica e cota. O relatorio afirma que o Service Control e um servico regional com datastores regionais e que seus metadados replicam globalmente em segundos.

Tier A (confirmed): o Google declarou que uma funcionalidade adicionada ao Service Control em 29 de maio de 2025 introduziu um novo caminho para verificacoes adicionais de politica de cota. Esse caminho foi distribuido regiao por regiao, mas nao foi exercitado durante o rollout porque a mutacao de politica que o acionaria ainda nao havia ocorrido. O Google declarou ainda que o caminho nao possuia tratamento de erro adequado e nao estava protegido por feature flag.

Tier A (confirmed): o Google informou que aproximadamente as 10:45 PDT de 12 de junho de 2025 uma alteracao de politica contendo campos em branco nao intencionais foi inserida nas tabelas regionais do Spanner usadas pelo Service Control e replicada globalmente. Quando instancias regionais do Service Control avaliaram a politica malformada, um caminho de null pointer causou crash loops em todas as regioes.

Tier A (confirmed): o Google relatou que a maior parte das regioes se recuperou apos um red-button desabilitar o caminho ofensivo, mas us-central1 teve recuperacao mais lenta porque reinicios das tarefas do Service Control criaram efeito de manada sobre a dependencia subjacente no Spanner e nao havia randomized exponential backoff.

Tier B (inferred): nao se tratou apenas de um release defeituoso. Foi uma falha de arquitetura do plano de controle em que replicacao global de metadados, isolamento insuficiente antes da ativacao e comportamento de reinicio converteram um unico objeto de politica malformado em indisponibilidade quase sistemica do caminho de admission control.

Tier C (unknown): o Google nao publicou contagens de crash por regiao, limiares exatos de saturacao do datastore nem a segmentacao interna do blast radius entre produtos que compartilhavam a dependencia do Service Control.

Declaracao de suposicao delimitada: a analise abaixo assume que todo caminho de API materialmente afetado dependia do mesmo caminho de admission control do Service Control e que a ordem de recuperacao foi dominada por pressao sobre o datastore regional, nao por mitigacoes ocultas especificas de produto.

Failure Surface Mapping

Seja S = {C, N, K, I, O} onde C e o plano de controle, N a camada de rede, K o ciclo de vida de chaves, I a fronteira de identidade e O a camada de orquestracao operacional.

C: superficie primaria de falha. Classes de falha: crash e timing. Binarios do Service Control entraram em crash loop apos consumirem dados malformados de politica de cota, e a recuperacao em regioes grandes se estendeu devido a pressao de thundering herd sobre o datastore regional.
O: superficie co-primaria. Classes de falha: omission e timing. O caminho defeituoso nao estava protegido por feature flag, nao foi estagiado com seguranca atras de um gate de ativacao por projeto e a recuperacao dependeu de rollout rapido de um red-button em vez de contencao precomprometida.
I: superficie secundaria. Classe de falha: omission. Admission control inclui autorizacao e verificacoes de politica; quando esse caminho fica indisponivel, acessos a APIs mediados por identidade falham mesmo sem comprometimento de credenciais.
N: nao foi a superficie iniciadora. Nao ha evidencia primaria de perda de transporte, instabilidade de roteamento ou degradacao do plano de pacotes.
K: nao implicada. Nao ha evidencia publicada de falha criptografica ou de ciclo de vida de chaves.

A falha portanto se projeta sobre C + O, com I como superficie dependente a jusante. Isso importa operacionalmente porque o objeto gatilho era metadado de politica, mas o mecanismo de indisponibilidade foi comportamento executavel do plano de controle.

Formal Failure Modeling

Defina o estado do plano de controle regional no tempo t como S_t = (P_t, B_t, D_t, R_t) onde P_t e o conjunto de politicas replicadas, B_t e a versao binaria do Service Control com seus feature gates ativos, D_t e a saude do datastore regional, e R_t e a pressao de reinicio.

A funcao de transicao e:

T(S_t) = \text{eval}\big(\text{replicate}(P_t), B_t, D_t, R_t\big)

O invariante exigido para continuidade do admission control e:

I_{\text{admission}} = \forall r \in R:\ \text{parse}(P_{t,r}) = \text{ok} \land \text{check}_r(P_{t,r}) \in \{\text{allow}, \text{deny}\}

O relatorio publicado implica a seguinte violacao:

\exists r \in R:\ \text{parse}(P_{t,r}) = \text{blank-field input} \to \text{null dereference} \to \text{crash loop}

Relevancia decisoria: se um plano de controle nao preserva I_admission sob objetos de politica malformados, mas ainda admissiveis pelo esquema, entao a replicacao global nao pode ser tratada como caminho benigno de metadados. Ela deve ser governada como caminho de execucao com controles de blast radius equivalentes aos controles de rollout binario.

Adversarial Exploitation Model

Classes de atacante:

A_passive: observador externo medindo assimetria de falha de APIs e ordenacao de recuperacao.
A_active: ator capaz de induzir alta concorrencia de requisicoes durante recuperacao degradada.
A_internal: operador privilegiado ou principal interno comprometido com autoridade para mutacao de politica.
A_supply_chain: ator capaz de alterar comportamento binario ou ferramental de geracao de politica antes do deploy.
A_economic: ator explorando indisponibilidade para gerar dano de mercado, contratual ou operacional.

Embora o Google afirme que este incidente nao foi um ataque, a arquitetura expoe um padrao exploravel. Se um objeto de controle replicado globalmente pode derrubar binarios de admission de forma deterministica, qualquer atacante que alcance o caminho de mutacao de politica ou a cadeia de geracao dessa politica ganha alavancagem de negacao desproporcional a fronteira de privilegio aparente.

Sejam a latencia de deteccao Δt, a largura da fronteira de confianca W e o escopo de privilegio P_s. Uma funcao simples de pressao e:

E \approx \Delta t \times W \times P_s

Tier B (inferred): neste evento, W foi efetivamente global porque o objeto de politica replicou em segundos entre regioes, e P_s foi alto porque o objeto influenciava verificacoes de autorizacao e cota em uma superficie ampla de produtos. A_internal e A_supply_chain sao, portanto, as classes mais perigosas para esse desenho, ainda que o evento observado tenha sido acidental.

Tier C (unknown): a evidencia publica nao estabelece quais fronteiras de aprovacao internas governavam a insercao especifica da politica, portanto os precondicionantes de exploracao por abuso de escrita de politica nao podem ser confirmados.

Root Architectural Fragility

A fragilidade raiz foi compressao de confianca entre metadados e execucao. O sistema tratou a propagacao de politica de cota como um problema de distribuicao de metadados, enquanto os binarios receptores trataram esses metadados como material de ativacao para um caminho executavel sujeito a crash.

Tres fraquezas estruturais sao evidentes.

Primeiro, o desenho acoplava replicacao global quase imediata a um caminho de codigo que nao havia sido exercitado com seguranca sob a condicao exata de ativacao. Rollout binario regiao por regiao nao forneceu seguranca porque cobriu colocacao de artefato, nao ativacao semantica.

Segundo, o sistema dependia de um red-button emergencial em vez de isolamento padrao preservador de invariantes. Um caminho perigoso dormente que esta globalmente presente, mas apenas manualmente suprimivel, nao esta contido; esta apenas nao revelado.

Terceiro, a logica de recuperacao assumia que reiniciar era progresso. Em regioes grandes, a pressao de reinicio amplificou a contencao no datastore porque faltava randomized exponential backoff. Isso converte a remediacao de um processo monotonicamente recuperador em um loop de realimentacao no qual restauracao parcial aumenta a carga sobre o gargalo.

Trata-se de um problema de doutrina de infraestrutura, nao de estilo de programacao. O primitivo ausente era segmentacao de ativacao para metadados de controle replicados globalmente.

Code-Level Reconstruction

O relatorio publico aponta para um caminho de politica malformada, ausencia de isolamento por feature gate e comportamento de crash por null pointer. A reconstrucao a seguir modela o fluxo vulneravel:

type Policy struct {
    QuotaChecks []QuotaCheck
}

type QuotaCheck struct {
    Name   string
    Target *Target
}

func EvaluateAdmission(req Request, p Policy, flags FeatureFlags) Decision {
    // Um desenho seguro rejeitaria ou colocaria em quarentena dados malformados
    // antes que atingissem o caminho de serving. Este fluxo nao faz isso.
    for _, qc := range p.QuotaChecks {
        if flags.AdditionalQuotaChecks {
            // Fallback inseguro: assume que qc.Target sempre existe.
            if qc.Target.ProjectID == req.ProjectID {
                ApplyQuotaRule(qc, req)
            }
        }
    }
    return Allow()
}

func Serve(req Request, store PolicyStore, flags FeatureFlags) Decision {
    policy := store.LoadLatest(req.Service)
    return EvaluateAdmission(req, policy, flags)
}

Um redesenho seguro exige tres guardas antes de servir trafego:

validacao de esquema que rejeite objetos de politica em branco ou estruturalmente incompletos antes da replicacao;
ativacao default-off via feature gate por projeto ou por regiao;
comportamento fail-open ou modo degradado para extensoes opcionais de cota quando o caminho opcional falhar.

Sem esses controles, politica se torna material de injecao de falha executavel.

Operational Impact Analysis

Tier A (confirmed): o Google relatou impacto global em um conjunto amplo de produtos, incluindo IAM, Cloud Storage, BigQuery, Compute Engine, Cloud Run, Cloud DNS, Gmail, Drive, Meet e Google Docs, com 503 elevados em requisicoes externas de API.

Tier A (confirmed): o Google informou que workloads de streaming e recursos IaaS ja em execucao nao foram impactados, o que implica que o blast radius dominante se concentrou em admission control e caminhos de serving, nao no dataplane de workloads previamente estabelecidos.

Sob a suposicao delimitada de que todos os deployments regionais do Service Control consumiram o mesmo objeto de politica malformado, a razao de blast regional e aproximadamente:

B = \frac{\text{affected\_nodes}}{\text{total\_nodes}} \approx 1

Essa razao e decisoria porque mostra que o evento se comportou como falha global de modo comum, nao como falha regional independente. Quando B se aproxima de 1, pressupostos convencionais de failover entre regioes perdem valor porque a dependencia compartilhada de admission atravessa as fronteiras de isolamento regional.

As implicacoes de latencia e throughput tambem sao claras. Crash loops colapsam o throughput em direcao a zero para requisicoes de controle nao cacheadas ou recentemente admitidas, enquanto tempestades de reinicio ampliam a latencia no datastore de suporte. O atraso de recuperacao em us-central1 demonstra que a carga pos-gatilho pode exceder o envelope de capacidade em estado estavel do substrato de politica mesmo depois de a logica defeituosa ser desabilitada.

Enterprise Translation Layer

CTO: tratar metadados de controle replicados globalmente como risco equivalente a codigo. Sucesso no rollout binario nao prova ativacao segura.
CISO: o objetivo de controle nao e apenas integridade de identidades e chaves, mas integridade dos caminhos de mutacao de politica de autorizacao que podem negar servico sem roubar credenciais.
DevSecOps: staging precisa exercitar caminhos de codigo dormentes com mutacoes sinteticas de politica, nao apenas distribuir binarios. Release seguro exige testes de ativacao, quarentena de esquema e drills de red-button com latencia de rollback auditada.
Board: diversificacao regional nao neutraliza dependencia comum de plano de controle. Alegacoes de resiliencia devem ser descontadas enquanto o provedor nao demonstrar segmentacao do plano de controle e independencia dos canais de recuperacao.

STIGNING Hardening Model

Prescricoes de controle:

isolar a aprovacao de mutacao de politica da replicacao global, introduzindo uma camada de quarentena que valide semantica antes de qualquer fan-out entre regioes;
segmentar a logica opcional do Service Control em modulos desabilitaveis independentemente com comportamento fail-open ou degradacao limitada quando a seguranca permitir;
exigir feature flags default-off para todas as novas verificacoes de admission, com ativacao primeiro em tenants internos e depois em regioes de baixo blast radius;
impor governadores de recuperacao conscientes do datastore para que tarefas reiniciadas usem randomized exponential backoff e limites de concorrencia derivados de telemetria de saturacao em tempo real;
manter monitoramento e publicacao de status fora de banda, sem compartilhar o mesmo substrato de controle em falha;
preservar rollback seguro de migracao versionando binarios e esquemas de politica, permitindo retorno regional para um par (binary, policy-schema) previamente validado.

Diagrama estrutural ASCII:

        [Policy Authoring]
                |
                v
      [Semantic Quarantine + Schema Gate]
                |
        +-------+--------+
        |                |
        v                v
 [Canary Region]   [Internal Projects]
        |                |
        +-------+--------+
                |
                v
   [Regional Replication Controller]
      |          |           |
      v          v           v
 [SC us-east] [SC eu-west] [SC ap-south]
      |          |           |
      +----------+-----------+
                 |
                 v
      [Out-of-Band Status + Telemetry]

O controle essencial nao e mais teste em abstrato. E estreitar o dominio de ativacao para que uma politica malformada nao se torne simultaneamente uma condicao executavel global.

Strategic Implication

Tipo primario do evento: systemic cloud fragility.

Em um horizonte de 5-10 anos, este incidente tem tres implicacoes. Primeiro, alegacoes de resiliencia em cloud dependerao crescentemente de planos de controle arquiteturalmente particionados em relacao a sistemas de politica replicados globalmente, nao apenas de deploy regional. Segundo, desenhos empresariais de disaster recovery que dependem de APIs de plano de controle do provedor durante uma indisponibilidade permanecerao estruturalmente frageis ate que tais dependencias sejam removidas explicitamente. Terceiro, provedores exigirao governanca mais forte para transicoes de metadados para execucao, porque plataformas modernas codificam autorizacao, cota e roteamento como objetos de controle propagados rapidamente.

A licao de longo prazo e que falhas de modo comum continuarao migrando de compute e storage para planos de admission, politica e orquestracao. Empresas devem modelar esses planos como dominios de falha de primeira classe.

References

Conclusion

A indisponibilidade de 12 de junho de 2025 no Google Cloud foi uma falha de modo comum do plano de controle produzida pela interacao de quatro condicoes: metadados de politica replicados globalmente, isolamento insuficiente de ativacao, logica de admission sujeita a crash e comportamento de recuperacao que amplificou pressao no datastore em regioes grandes. O remedio arquitetural e tratar propagacao de politica como canal privilegiado de execucao, nao como canal inerte de configuracao.

Para consumidores empresariais, a pergunta pratica de controle e direta: quais fluxos criticos de recuperacao ainda dependem de um plano de admission ou gerenciamento do provedor que pode falhar globalmente sob condicoes compartilhadas de metadados. Qualquer dependencia nao respondida nesse ponto e um passivo de resiliencia nao resolvido.

STIGNING Infrastructure Risk Commentary Series Engineering Under Adversarial Conditions