Airframe

Por que o Airframe

Barreiras de proteção como código

Cada mudança na infraestrutura e no pipeline de um produto, seja quem for ou o que for que a escreveu, é verificada por regras testadas no seu merge request, e o seu plano de novo antes de qualquer aplicação. As pessoas aprovam para que serve uma mudança; as regras verificam como ela é feita.

Como uma mudança é verificada

  1. As regras são código, com testes

    O pacote de políticas é um conjunto de regras do Open Policy Agent no repositório control-plane. O Conftest as executa sobre o código Terraform e o arquivo de pipeline de um produto no merge request, e sobre o plano do Terraform antes de cada apply; a partir da versão da plataforma 2026.10.01-1, os Dockerfiles que um produto declara para os seus builds são verificados em todo merge request que muda um chamado Dockerfile, Dockerfile.* ou *.Dockerfile. Por convenção, cada regra traz um caso que deve passar e um que deve falhar, e uma nova regra de negação costuma passar a sua primeira versão como aviso; o pipeline do próprio pacote executa todos os testes a cada mudança.

  2. Uma validação que um produto não pode desligar

    As políticas de execução de pipelines do GitLab no projeto security-policies injetam jobs que o próprio arquivo de pipeline de um repositório não pode remover nem substituir: a verificação de integridade do controle de aprovação em cada pipeline do grupo, e a validação e a evidência de testes em cada pipeline de um repositório de produto.

  3. A mensagem diz o que está errado

    Uma regra que falha nomeia o recurso que avaliou e o que está errado nele, e muitas também dizem o que fazer no lugar, com palavras escritas para quem as ler depois, uma pessoa ou um agente de código.

  4. Só os componentes da plataforma fazem deploy

    O arquivo de pipeline de um produto só pode incluir os componentes de CI do próprio repositório control-plane, e nenhum dos seus próprios jobs pode declarar um ambiente de deploy. Um componente de qualquer outro lugar é negado, e o controle de aprovação faz falhar um pipeline que inclua uma versão revogada da plataforma.

  5. As pessoas aprovam a intenção

    Cada merge request para um branch padrão precisa da aprovação de uma pessoa nomeada no catálogo que não o escreveu nem fez commits nele, nunca de um papel. Hoje, em todos os repositórios exceto security-policies, que contém as próprias regras de aprovação, ele também precisa da aprovação do controle de aprovação, que a acrescenta só quando os responsáveis que o catálogo nomeia aprovaram o último commit: um aumento de orçamento ou um serviço novo precisa de um líder de domínio, e quando o líder não tem conta, como na demo, a equipe de plataforma o substitui.

Experimente

Escolha uma mudança que uma equipe poderia propor. O veredito, a regra e a mensagem são os do pacote de políticas, julgados na versão da plataforma que este site descreve.

Uma mudança proposta
Negado

Arquivo: main.tf

resource "google_storage_bucket_iam_member" "public" {
  bucket = "orders-exports-k3d8"
  role   = "roles/storage.objectViewer"
  member = "allUsers"
}
  • Negado iam.public-principal

    google_storage_bucket_iam_member.public: public principal "allUsers" is not allowed; expose through external-ingress behind IAP

    Nada é concedido a todo mundo, e a negação é aplicada. Uma rota pública pelo ingresso externo da plataforma, atrás do IAP, está projetada; hoje um serviço público recebe uma rota na borda compartilhada, atrás do login único.

  • Aviso naming.raw-resource

    google_storage_bucket_iam_member.public: a raw google_storage_bucket_iam_member in a product root needs a reason in the merge request (platform approval); compose the registry's modules where one covers it (skill airframe-naming)

    Um recurso que o produto declara por conta própria, em vez de compor um módulo, precisa de uma justificativa no merge request. O pacote de políticas emite um aviso; a aprovação da plataforma para ele está projetada, e hoje um aviso não bloqueia nada.

Essas regras rodam no seu notebook com airframe validate, e de novo no job validate:policy do merge request.

O que torna isso verdade

Os testes do pacote de políticas rodam a cada mudança nele.
O job policy:test do repositório control-plane executa os testes unitários do Conftest e os casos que devem passar e falhar em cada merge request que muda o pacote, e o GitLab só faz o merge de um merge request cujo pipeline tem sucesso. Que uma regra nova traga os seus próprios testes é uma convenção mantida na revisão, não uma verificação.
Um repositório de produto não pode pular a validação.
A política de execução de pipelines de produtos no projeto security-policies injeta os componentes validate e build-test em cada pipeline dos repositórios dos grupos de jornada, e o GitLab não deixa o próprio arquivo de um projeto remover nem substituir um job injetado.
O arquivo de pipeline de um produto inclui só os componentes da plataforma, e nenhum dos seus próprios jobs faz deploy.
As regras de pipeline do pacote negam uma inclusão que não seja um dos oito componentes nomeados do repositório control-plane, um job que declara um ambiente e um job que dispara outro pipeline; a validação injetada as executa sobre o arquivo do produto.
A aprovação de uma pessoa a um merge request para um branch padrão vem de uma pessoa nomeada, não de um papel.
A política de aprovação lista os seus aprovadores pelo nome e exclui o autor e quem fez commits. O job policy:approvers do projeto security-policies relata qualquer papel, grupo ou nome que difira das pessoas ativas do catálogo com uma conta no GitLab. O que mantém a lista ali é a aprovação de cada mudança por uma pessoa nomeada, nunca a do seu autor. A conta de serviço do controle de aprovação é a única aprovadora de uma política à parte e não pode dar a aprovação da pessoa.
Uma regra que nega impede a mudança.
Uma negação faz falhar o job de validação injetado, e o GitLab só faz o merge do merge request de um produto quando o seu pipeline tem sucesso; na main, o job de políticas do componente tf-apply executa o pacote sobre o plano, e o apply precisa que esse job passe. As regras de custo rodam, em vez disso, no executor: a sua recusa faz falhar a verificação de status Airframe cost do merge request, que precisa passar antes que o GitLab faça o merge, e interrompe o plano na main.