Identidades e acesso

No Airframe, nenhuma conta de uso diário pode mudar a infraestrutura de produção, e nenhuma máquina tem uma senha que funcione para sempre. Os pipelines recebem identidades que duram uma hora e só servem para um job; as pessoas podem olhar, e quando realmente precisam mudar algo à mão, pedem um acesso com tempo limitado, aprovado por outra pessoa e registrado. Esta página explica como as duas coisas funcionam, um nível abaixo da página de zero privilégio permanente.

Quem age sobre a plataforma

Três tipos de identidade tocam o Google Cloud:

As identidades de pipeline são contas de serviço do Google com as quais o Terraform roda. Cada raiz da plataforma tem a sua, como a da fábrica de projetos, e cada produto tem suas próprias identidades de plan e de apply em cada um dos seus projetos.
As identidades de execução pertencem aos serviços em funcionamento de um produto. Cada serviço recebe a sua, com exatamente os segredos, o banco de dados e os tópicos que usa.
As pessoas entram com suas contas da organização. O acesso delas vem por grupos do Google que os reconciliadores do catálogo preenchem, como o grupo de uma equipe ou o grupo dos usuários de um produto.

Como um job de pipeline obtém uma identidade

Um job de pipeline nunca tem uma chave. Em vez disso, ele usa a federação de identidade de carga de trabalho:

O job pede ao GitLab um token assinado. O token diz a qual repositório o job pertence, em qual ambiente ele implanta e se sua branch é protegida.
O provedor de identidade do Google Cloud verifica o token. Um token de fora do grupo projectairframe no GitLab é recusado antes de qualquer outra leitura, de modo que uma cópia de um repositório no espaço pessoal de alguém não recebe nada.
O provedor junta os três dados em um só valor, por exemplo, o repositório de pedidos, o ambiente prod e true para protegida. Cada identidade é vinculada a exatamente um desses valores.
Se o valor corresponde, o job recebe um token de acesso para essa única identidade, válido por uma hora.

Um job em uma branch sem proteção, em outro repositório ou em outro ambiente não corresponde a nenhum vínculo e não recebe nada. Um repositório renomeado perde seus vínculos, e o caminho de um produto removido nunca é reutilizado, de modo que um repositório novo não pode herdar o acesso de um antigo.

Identidades de plan e identidades de apply

Cada produto tem duas identidades de pipeline em cada um dos seus projetos:

A identidade de plan pode ler o projeto e o estado do Terraform, e não muda nada. Ela não é vinculada a nenhum repositório: só o executor pode usá-la, quando o controle de aprovação inicia uma execução na aprovação de um merge request.
A identidade de apply pode mudar o projeto. A de produção só responde a um job do próprio repositório do produto, em uma branch protegida, no ambiente prod, ou grafana para a raiz que publica os painéis do produto. A de não produção responde a np, e o executor também a usa para construir a prévia de um merge request.

O executor pode usar todas as identidades de plan e todas as identidades de apply de não produção, e nenhuma identidade de apply de produção. Assim, nada que roda antes de um merge pode mudar a produção.

O que as pessoas recebem

Os papéis permanentes das pessoas são papéis de leitura: elas podem ver um projeto e seus logs, não mudá-lo. A única exceção, bem restrita, é que a equipe de um produto pode adicionar uma versão nova de um dos segredos do produto; ela nunca pode ler um.

Quando uma pessoa precisa de mais, ela pede uma concessão do Privileged Access Manager com um motivo escrito. O Airframe tem quatro tipos:

Concessão	O que dá, quem aprova e quanto dura
Nível 1	Leitura dos logs, métricas e estado de um projeto de não produção, hoje só o projeto de execução da plataforma, `lk-runtime-np`. Aprovada por: quem pede, com um motivo. Dura: 1 hora.
Nível 2	Papéis administrativos na pasta da organização de demonstração, para uma correção à mão. Aprovada por: outro membro do grupo de plataforma. Dura: 2 horas.
Apply da plataforma	Os papéis para as poucas raízes da plataforma que ainda são aplicadas a partir de um notebook. Aprovada por: outro membro do grupo de plataforma. Dura: 2 horas.
Organização	Os papéis para mudanças no nível da organização. Aprovada por: outro membro do grupo de plataforma. Dura: 2 horas.

Os membros do grupo de emergência, lk-breakglass@, podem pedir as três primeiras concessões. A concessão de organização é pedida pelos membros do grupo de plataforma, lk-platform@, e todas as aprovações também vêm desse grupo. O Privileged Access Manager nunca deixa quem pede aprovar o próprio pedido nas concessões que precisam de aprovação. Toda concessão fica no registro de auditoria.

Hoje o nível 1 existe só no projeto de execução de não produção da plataforma. Nenhuma fábrica de projetos o cria ainda para o projeto de não produção de um produto, então as concessões de nível 1 nos projetos dos produtos estão projetadas.

Três raízes da plataforma ainda são aplicadas a partir de um notebook com uma concessão assim: as políticas da organização, a configuração de auditoria e a raiz que cria o provedor de identidade e a identidade de cada raiz da plataforma. Um pipeline que pudesse reescrever o modelo de identidades seria o mais poderoso da plataforma, então ele fica atrás de uma segunda pessoa. Cada uma dessas raízes é planejada todo dia por um pipeline agendado cuja identidade só pode ler, de modo que uma mudança feita com uma concessão aparece como desvio em menos de um dia.

Hoje uma só pessoa opera a plataforma, e o segundo aprovador é a segunda conta do mantenedor: o mecanismo é aplicado, mas a separação entre duas pessoas ainda não é real.

Sem chaves

Uma chave de conta de serviço é uma senha de longa duração para uma identidade de máquina, e o Airframe não permite nenhuma. As políticas da organização na pasta da organização de demonstração proíbem criar ou enviar chaves, e uma política de negação bloqueia a criação de chaves para todos, exceto o grupo de emergência, a conta de administrador da inicialização e o próprio agente de serviço do Privileged Access Manager. O pacote de políticas também recusa uma chave declarada no Terraform. As credenciais vêm do token de um job ou, para um serviço em funcionamento, do servidor de metadados do lugar onde ele roda.

A única conta de administrador

Uma conta dedicada tem Organization Administrator, o papel mais alto da organização. Ela é usada só para a inicialização e para procedimentos excepcionais, e no resto do tempo fica desconectada. Um job agendado no repositório landing-zone pergunta todo dia ao Policy Analyzer do Google quem tem qual papel na organização, e falha se alguma pessoa tem ali um papel diferente do Organization Administrator dessa conta, ou se algum grupo tem algum.

Onde fica

No repositório landing-zone: