landing-zone

O repositório landing-zone constrói a parte do Google Cloud sobre a qual cada produto se apoia: as pastas e políticas da organização, as redes compartilhadas, as fábricas que criam os projetos e as identidades de cada produto, e o registro de auditoria. É também onde vive o design escrito da plataforma: a especificação, os contratos que cada repositório implementa, os registros de decisões e um manual ilustrado. Se você quer saber por que algo no Airframe é como é, a resposta costuma estar na pasta docs deste repositório.

Para que serve

Uma landing zone é o terreno preparado de uma organização na nuvem: a estrutura, as regras e os serviços compartilhados que precisam existir antes que qualquer equipe possa implantar algo com segurança. No Airframe, tudo isso é código Terraform neste repositório, aplicado por pipelines, então a base é revisada e registrada como todo o resto.

O que ele contém

As raízes, cada uma um diretório de código Terraform com seu próprio estado e sua própria identidade:

organisation: as políticas da organização toda, como não permitir chaves de contas de serviço nem endereços públicos de bancos de dados, e a política de negação que protege a pasta da organização de demonstração.
folders: uma pasta por jornada, domínio e contexto, a partir do catálogo.
project-factory: uma fábrica por domínio, que cria os dois projetos de cada produto, suas identidades de plan e de apply, seus lugares para o estado do Terraform, seu orçamento quando ele tem faturamento, e sua saída Ready; e uma para os projetos da própria plataforma.
groups: os grupos do Google das equipes, dos líderes e dos usuários de cada produto, com seus membros a partir do catálogo.
network e perimeters: as duas redes compartilhadas, produção e não produção, a borda compartilhada que dá a cada produto seu nome de host atrás do login único, o DNS, e os perímetros do VPC Service Controls, que hoje funcionam em modo de teste.
wif e pam: o provedor de identidade que dá aos jobs de pipeline suas identidades de curta duração, e as concessões do Privileged Access Manager para as pessoas.
audit e state: a exportação do registro de auditoria e os buckets que guardam o estado do Terraform de cada raiz.

Os documentos, em docs/:

architecture.md, a especificação: o que é construído e por quê, com as alternativas consideradas;
contracts.md: os nomes e os formatos que cada repositório precisa usar, dos campos do catálogo aos nomes de host;
adaptations.md, bootstrap.md e bootstrap-log.md: onde esta implementação se afasta do design original, as poucas coisas criadas à mão no início, e o registro de cada passo à mão desde então;
adr/, rehearsals/ e reviews/: decisões, ensaios de reconstrução e de aposentadoria, e revisões da implementação com o que respondeu a cada achado;
guides/: o manual, um guia ilustrado por visão da plataforma, começando pela visão geral.

Como ele se conecta

Ele lê o catálogo. As pastas, os grupos e as fábricas de projetos criam o que o catálogo descreve, e a cadeia depois de um merge no catálogo inicia primeiro o pipeline deste repositório.
Todo o resto o lê. A saída Ready de uma fábrica de projetos diz às raízes do próprio produto, às raízes do GitLab do control-plane e às raízes do operations o que existe. A publicação da rede diz às fábricas quais projetos estão conectados.
Os produtos publicam para ele. As rotas de um produto são publicadas em um bucket compartilhado, e a raiz de rede compõe a borda compartilhada a partir delas, então um produto nunca tem as credenciais da borda.

Quem o muda, e como

As mudanças são merge requests aprovados pela equipe de plataforma. Na main, o pipeline planeja cada raiz, roda o pacote de políticas sobre o plano e o aplica com a identidade própria daquela raiz. As raízes de rede e de perímetros planejam depois que as fábricas aplicaram, então os projetos de um produto novo chegam à rede no mesmo pipeline.

Três raízes não são aplicadas pelo pipeline: organisation, audit e wif. Um pipeline que pudesse reescrever o modelo de identidades seria o mais poderoso da plataforma, então elas são aplicadas a partir do notebook de um mantenedor com uma concessão de tempo limitado que outro membro do grupo de plataforma aprova. O pipeline ainda as planeja todo dia com uma identidade só de leitura, então qualquer mudança feita com uma concessão aparece como desvio.

Todo dia, o pipeline agendado também planeja cada raiz para pegar desvios, e pergunta ao Policy Analyzer do Google quem tem qual papel na organização, falhando se alguém tem um que não deveria.

Onde fica

No repositório landing-zone: