Airframe

Por que o Airframe

Zero privilégio permanente

Nenhuma conta de uso diário de uma pessoa, inclusive a de um mantenedor, tem um papel que possa mudar a infraestrutura de produção. Fora de uma concessão com tempo limitado, o que a muda é um job de pipeline cuja identidade de curta duração está vinculada a um repositório, uma ref protegida e um ambiente.

Como um job obtém uma identidade, e como uma pessoa obtém acesso

  1. Um job prova onde roda

    Um job de pipeline pede ao GitLab um token assinado que nomeia seu repositório, seu ambiente e se sua ref é protegida. A federação de identidade de cargas de trabalho do Google Cloud verifica o token; um token de fora do grupo projectairframe, inclusive o de um fork em um espaço de nomes pessoal, é recusado antes de qualquer vínculo ser lido.

  2. Uma identidade de apply responde a um só repositório

    Cada identidade de apply está vinculada ao repositório do seu produto, em uma ref protegida, no seu próprio ambiente: a de produção responde a jobs no ambiente prod, e em grafana para os painéis do produto. Um job em um branch não protegido, em outro repositório ou em outro ambiente não obtém nada.

  3. Sem chaves

    Chaves de contas de serviço não podem ser criadas nem enviadas: uma política da organização na pasta da organização de demonstração proíbe as duas coisas, e uma política de negação bloqueia a criação de chaves para todos, exceto o grupo de acesso de emergência, a conta de administrador do bootstrap e o agente de serviço do Privileged Access Manager. As credenciais vêm do token do job ou do servidor de metadados.

  4. Pessoas recebem concessões, não papéis administrativos permanentes

    Um mantenedor que precisa mudar algo solicita uma concessão do Privileged Access Manager com uma justificativa. Uma concessão de papéis administrativos precisa da aprovação de outro membro do grupo de plataforma e dura no máximo duas horas; o acesso de leitura aos logs e ao estado de um projeto de não produção é autoaprovado e dura uma hora. Cada concessão fica no log de auditoria.

  5. Uma imagem é atestada e depois admitida

    O compilador confiável compila cada imagem a partir do commit aprovado. O executor confere o registro do Cloud Build dessa compilação antes que uma identidade separada assine o atestado de compilação, e a promoção adiciona um segundo. Todo serviço que o módulo de Cloud Run do golden path implanta adere à política do Binary Authorization que o seu projeto tiver, que em produção só admite uma imagem que tenha os dois; a política é escrita assim que os projetos de um produto são faturados. O controle de aprovação e este site funcionam com a mesma regra.

  6. Uma versão com falha pode ser revogada

    As ferramentas de pipeline da plataforma são publicadas como versões datadas. Revogar uma, com um merge request na lista de versões permitidas, faz o controle de aprovação falhar todo novo pipeline que ainda a inclua, e nomeia a versão para a qual migrar.

Experimente

Escolha um job do GitLab. Esta é a identidade que ele pode obter, se houver, a partir dos vínculos que o código da plataforma declara na versão que este site descreve.

projectairframe/shop/store/ordering/orders · prod · protegida

Pode obter orders-apply@lk-store-orders-8k2p.iam.gserviceaccount.com

pelo vínculo do repositório, do ambiente e da ref protegida

Atributo: attribute.airframe/projectairframe/shop/store/ordering/orders/prod/true

O que torna isso verdade

Nenhuma conta de uso diário de uma pessoa tem um papel permanente que possa mudar a infraestrutura de produção.
A raiz de pastas e as fábricas de projetos concedem às pessoas papéis de leitor e de leitor de logs, e o template do produto permite que uma equipe adicione versões dos seus segredos de produção, nunca que as leia. Papéis administrativos só chegam às pessoas por concessões do Privileged Access Manager. A administração da organização fica com uma única conta de administrador dedicada, usada só para o bootstrap e os procedimentos excepcionais; um job agendado do Policy Analyzer falha se, no nó da organização, essa conta tiver qualquer papel além de Organization Administrator, ou qualquer outra pessoa ou grupo tiver um papel permanente.
Só um job do próprio repositório do produto, em uma ref protegida e no ambiente certo, pode obter sua identidade de apply.
A fábrica de projetos vincula cada identidade de apply ao atributo composto de caminho do repositório, ambiente e proteção da ref, só com o valor protegido; o provedor do pool de identidades recusa qualquer token de fora do grupo projectairframe.
Nenhuma chave de conta de serviço pode ser criada ou enviada sob a pasta da organização de demonstração.
As políticas da organização na pasta desativam a criação e o envio de chaves para qualquer principal, e uma política de negação do IAM bloqueia a criação de chaves para todos, exceto o grupo de acesso de emergência, a conta de administrador do bootstrap e o agente de serviço do Privileged Access Manager.
O acesso administrativo de um mantenedor dentro da pasta da organização de demonstração é temporário, e outro membro do grupo de plataforma o aprova.
Os direitos do Privileged Access Manager que concedem papéis administrativos exigem a aprovação de outro membro do grupo de plataforma, nunca a da própria conta do solicitante, e duram no máximo duas horas; o único direito de nível 1, no projeto de não produção lk-runtime-np da plataforma, concede acesso de leitura a esse projeto por uma hora, autoaprovado.
Um serviço de produto implantado pelo golden path só roda uma imagem que a plataforma compilou e promoveu.
O módulo de Cloud Run do golden path faz todo serviço aderir à política do Binary Authorization que o seu projeto tiver, que no projeto de produção de um produto faturado é aplicada e exige os atestados build e promote; a raiz trusted-builder só permite assinar com suas chaves ao atestador de compilação e ao promotor de artefatos.
Uma versão revogada não roda nenhum pipeline novo.
O job de integridade do controle de aprovação, que a política de execução de pipelines do grupo injeta em todo pipeline, lê as versões permitidas no main do control-plane e faz falhar um pipeline que inclua uma revogada; o executor faz a mesma verificação antes que uma execução de merge request ou de versão tenha as credenciais de um produto.