Consulta antes de mutar: como agentes devem interagir com sua infraestrutura

O problema com plano, revisão, aplicação

A infraestrutura como código foi projetada em torno de mudanças na velocidade humana: escrever um plano, revisá-lo, aplicá-lo e usar instantâneas de estado para saber o que foi gerenciado anteriormente. Isso funciona melhor quando os escritores são poucos e as mudanças são infrequentes.

Os agentes mudam essas suposições. Eles operam continuamente e múltiplos atores podem tocar os mesmos recursos ao mesmo tempo. A deriva não é mais excepcional. É inevitável e implacável.

Ferramentas de IaC canônicas como Terraform ainda são importantes porque representam a intenção. O que foi enfraquecido é sua capacidade de refletir a realidade atual. Os agentes raramente possuem o quadro completo. Eles geralmente operam em escopos restritos, trabalhando em uma parte da infraestrutura que outros agentes, outras ferramentas ou humanos também estão tocando. Nesse mundo, um agente encontrará regularmente infraestrutura que foi mutada fora de banda, fora de qualquer sistema de IaC que nominalmente a gerencia.

Consultar antes de mutar lida com esse caso. Leia o estado da nuvem ao vivo, compare-o com a política, aplique um portão de política limitado, mutue apenas o que está fora da política e, em seguida, verifique. Cada execução começa da realidade em vez de uma visão em cache.

A demonstração leva cerca de dez minutos e usa a criptografia de bucket do Google Cloud Storage, mas o padrão é agnóstico ao provedor.

Consultar antes da mutação

A correção vem da consulta ao estado ao vivo antes de agir. A segurança vem de algo separado: portões de política que limitam o que uma única execução pode fazer. Bloqueios de localização, limites de recursos, tetos orçamentários, listas de permissão. Dois padrões, dois trabalhos. A consulta antes da mutação agente complementa abordagens de IaC centralizadas que aproveitam instantâneas de estado. Os portões de política substituem a reunião de revisão.

O loop combinado é correto por padrão porque lê a realidade, e seguro por padrão porque não pode fazer mais do que o portão permite. Os agentes podem executá-lo continuamente. Os humanos podem executá-lo manualmente. A saída converge de qualquer maneira.

stackql implementa esse padrão. Qualquer recurso em qualquer nuvem suportada pode ser lido com SQL e mutado com SQL onde o provedor expõe métodos de mutação. Kubernetes resolveu a reconciliação dentro do cluster, mas nada reconcilia em sua nuvem. Essa lacuna é onde esse padrão pertence. A demonstração usa o Google Cloud Storage porque a superfície de mutação é limpa, mas a forma é a mesma para AWS S3, segredos do Vault, configurações da organização do GitHub ou qualquer outra coisa que um agente precise raciocinar.

Configuração

Você precisa de três coisas:

• Docker (para executar stackql sem instalar nada mais)
• Um projeto do Google Cloud com credenciais que podem ler buckets e atualizar a configuração de criptografia, além de uma chave do Cloud KMS existente que você deseja impor
• Cerca de dez minutos

Clone a pasta do tutorial do repositório stackql:

git clone https://github.com/stackql/stackql.git
cd stackql/docs/tutorials/query-before-mutation-01

Copie o arquivo de ambiente de exemplo e adicione suas credenciais de conta de serviço:

cp .env.sample .env
# Em seguida, edite .env para definir:
# GOOGLE_CREDENTIALS=<service-account-json-em-uma-linha>

Inicie um shell interativo stackql:

docker compose run --rm --entrypoint bash stackql
# então dentro do contêiner:
stackql shell

Puxe o provedor do Google do registro. Isso só precisa acontecer uma vez por sessão de shell:

REGISTRY PULL google v26.07.00432;

Você está pronto.

Consultar o estado ao vivo

Pergunte à API do GCS quais buckets existem e qual criptografia está atualmente aplicada a cada um.

SELECT name, location, encryption 
FROM google.storage.buckets 
WHERE project = 'seu-id-do-projeto';

Saída esperada em um projeto com uma mistura de configurações de criptografia:

| name                       | location | encryption                                    |
| demo-app-bucket1           | US       | null                                          |
| demo-app-bucket2           | US       | null                                          |
| stackql-demo-src-bucket    | US       | null                                          |
| stackql-encrypted-bucket-1 | US       | {"defaultKmsKeyName":"projects/.../keys/..."} |

Três buckets mostram criptografia como nula, significando chaves de criptografia gerenciadas pelo Google (GMEK), o padrão. Um já usa uma chave gerenciada pelo cliente. Sob uma política que exige chaves gerenciadas pelo cliente, três buckets estão fora da política.

Uma instantânea de estado pode lhe dizer o que o Terraform configurou anteriormente. Esta consulta lhe diz o que o GCS relata agora, independentemente de quem criou ou mudou o bucket. Se dez agentes e dois humanos estão todos tocando este projeto em vários momentos durante o dia, a consulta ainda retorna a verdade atual toda vez que você a executa. Essa é a propriedade sobre a qual o padrão é construído.

Aplicar um portão de política

Três buckets não correspondem à política. Antes de mutar, o agente precisa provar que está autorizado a fazê-lo. É para isso que serve o portão de política.

Um portão é qualquer coisa que limite o que uma única execução do agente pode fazer. Escopo por projeto ou localização, limite o número de recursos alterados ou imponha uma lista de permissão explícita. A forma depende de quanta liberdade o agente tem e quanto você está disposto a perder em uma execução ruim.

Para esta demonstração, dois portões cobrem a maior parte do risco. O primeiro é um bloqueio de localização. O agente deve agir apenas em buckets na localização para a qual foi configurado. Esta é uma cláusula WHERE em cada consulta e mutação:

WHERE location = 'US'

Trivial quando os buckets do projeto estão em uma localização. Em produção, os agentes se movem entre localizações com base na tarefa, e tocar um bucket na região errada pode significar agir sobre recursos em um ambiente que o agente não tem negócios. Uma cláusula, mas é a diferença entre uma ação limitada e uma ação ilimitada.

O segundo portão é um limite de contagem. Antes de executar uma mutação em vários buckets, pergunte à API quantos o mutação tocaria:

SELECT COUNT(*) 
FROM google.storage.buckets 
WHERE project = 'seu-id-do-projeto';