A role que qualquer repo pode vestir: uma trust policy OIDC sem sub fixado
O desafio
A Northwind permite que o GitHub Actions faça deploy na AWS sem chaves de longa duração: um workflow apresenta um token OIDC do GitHub de curta duração e assume uma role. Duas roles confiam nesse provider. Uma serve para fazer o deploy do site de marketing, a outra é admin total na conta de produção. Ambas confirmam que o token é de fato um token do GitHub Actions. Só uma delas também confirma de qual repositório o token veio. Leia as duas trust policies e diga o nome da role que qualquer workflow em todo o github.com pode assumir.
O que você vai aprender
- Explicar o que significam as claims aud e sub de um token OIDC do GitHub
- Reconhecer que aud é uma constante compartilhada e não prova nada sobre o repo
- Identificar uma trust policy sem a condição sub como criticamente aberta
- Descrever o risco de wildcards StringLike em sub e ref
- Entender que a confiança deve ficar mais restrita à medida que o privilégio da role cresce
Habilidades testadas
Pré-requisitos
- O que são uma role IAM e uma trust policy
- A ideia de federação OIDC para CI
Como funciona
O CI sem chaves funciona assim: um workflow apresenta um token OIDC de curta duração e assume uma role da AWS. A trust policy da role decide quem pode fazer isso, então ela é toda a fronteira.
A claim aud de um token do GitHub tem o mesmo valor em toda execução do GitHub Actions, em qualquer lugar; checá-la só prova que quem chama é algum workflow do GitHub. A claim sub é a que nomeia o repositório e a ref. Uma trust policy que checa aud mas não sub aceita um token gerado por um workflow de qualquer repositório no github.com, inclusive um que pertence ao atacante.
Por isso a role deve fixar sub nos repos e refs exatos permitidos e tratar wildcards com cuidado: repo:org/* admite qualquer repo da organização, e uma ref frouxa admite qualquer branch ou um pull request.
Erros comuns
- Responder
northwind-site-deploy. A policy dela fixasubem um repo e uma branch, então é a segura. - Achar que a checagem de
audajuda. Todo token do GitHub carrega o mesmoaud; ele não é um controle de escopo. - Supor que um atacante não consegue um token válido. Qualquer pessoa pode rodar Actions no próprio repo e receber um token OIDC genuíno do GitHub.
- Ver o privilégio como a falha. Direitos de admin pioram a situação, mas o bug é a condição
subausente.
Como se proteger
Fixe o subject e mantenha o privilégio proporcional ao escopo.
- Sempre adicione uma condição
sublistando os valores exatosrepo:org/name:ref:...permitidos. Nunca dependa só deaud. - Prefira
StringEqualsem subjects completos. Se precisar usarStringLike, eviterepo:org/*e refs frouxas; restrinja a repos e branches nomeados. - Separe privilégio baixo e alto: uma role de deploy de um site nunca deve ter a mesma abertura de uma role de admin, e roles de admin precisam da confiança mais restrita possível.
- Audite toda role de web identity em busca de
subausente ou com wildcard.