Resumo

  • id-token: write permite que um job ou workflow do GitHub Actions solicite um JSON Web Token OIDC; a própria documentação do GitHub diz que essa definição não concede permissão para gravar em recursos externos.
  • O provedor de nuvem avalia separadamente as condições de confiança configuradas e pode trocar o JWT por um token de acesso de curta duração. A decisão posterior do recurso é outra superfície de controle.
  • Uma afirmação verificável de autorização em nuvem conecta a revisão do workflow e as claims delimitadas, a revisão da política de confiança, a evidência de troca e sessão, o contexto de permissões efetivas, a decisão do recurso e uma observação do destino feita em outro momento.

“O pipeline tem acesso à nuvem por OIDC” pode ser uma descrição útil da implementação. Ela se torna enganosa quando comprime decisões distintas, administradas por partes diferentes, em um único veredito. O GitHub Actions pode emitir um token de identidade OpenID Connect para um job que tem permissão para pedi-lo. Um provedor de nuvem pode ser configurado para confiar no emissor do GitHub e conferir um conjunto escolhido de claims. Se a troca tiver êxito, o job poderá receber uma credencial de nuvem de vida curta.

Em seguida, o serviço de nuvem ainda decidirá uma solicitação concreta à luz de função, política do recurso, limite de permissões, política de sessão, controle organizacional, contexto da requisição e ação solicitada. Cada elo tem ator, instante e local de evidência próprios.

O GitHub define com clareza o primeiro limite. id-token: write deixa o workflow solicitar e usar um JWT OIDC; não dá ao workflow, por esse motivo, o direito de modificar outros recursos. Por isso, encontrar a permissão numa revisão de release não autoriza descrevê-la como privilégio final. O que o revisor aprendeu é limitado: aquele job podia solicitar um token de identidade do GitHub. Ele não sabe, só por isso, se a solicitação ocorreu, qual audience foi solicitada, quais claims foram devolvidas, se a nuvem confiou nelas ou se algum recurso aceitou depois uma ação.

A relação de confiança com a nuvem é outra configuração e outra decisão. A orientação do GitHub para provedores de nuvem afirma que o provedor valida as claims do token e, se a validação for bem-sucedida, fornece um token de acesso disponível ao job. É a política do provedor que transforma subject, audience, identidade do repositório, referência de workflow reutilizável ou outra claim disponível em condição de admissão. Um token pode estar bem formado e mesmo assim ser recusado por uma condição de confiança. Uma condição pode estar ampla demais, ou uma claim esperada pode ter desaparecido ou mudado.

Um token de nuvem pode ser emitido com escopo menor do que imagina quem prepara a release. E, no outro sentido, uma política do recurso pode negar a ação depois de uma troca federada bem-sucedida.

O caso da AWS torna a separação mais visível. A orientação do GitHub para AWS descreve a configuração da relação de confiança da AWS e recomenda avaliar a chave de condição OIDC sub numa política de confiança de função. Portanto, a existência de uma claim sub do GitHub não é o registro de uma sessão de função da AWS. Uma sessão de função, por sua vez, não é o registro de todas as permissões que ela tinha no contexto de uma solicitação. Política da função, limite de permissões, política de sessão, restrição organizacional, política de recurso e negação explícita podem moldar uma decisão específica. Este texto não audita nenhuma conta AWS; ele mostra por que a frase genérica “OIDC autorizou o deploy” deixa perguntas decisivas sem resposta.

Workflows reutilizáveis oferecem outra razão para preservar a ligação concreta. O GitHub documenta que o token de um job executado dentro de workflow reutilizável contém informações ordinárias do job e pode conter job_workflow_ref; o suporte a claims personalizadas varia entre provedores de nuvem. Um nome de workflow presente no repositório não prova que o provedor que confia no token verificou esse campo. Um chamador pode ser conhecido pelo GitHub e ainda assim não aparecer na claim que a condição de confiança consegue avaliar. Uma personalização posterior de claims de subject também pode mudar o formato que o provedor espera. São fatos de configuração a registrar, não lacunas a preencher com a palavra tranquilizadora “federado”.

Daí a necessidade de um recibo de autorização em nuvem com sete partes. Registre a revisão exata do workflow, a ref que o disparou, a identidade do job e o contexto de id-token: write. Registre de forma limitada a audience solicitada e as claims resultantes, sem expor um token utilizável. Registre a versão do provedor de identidade e da política de confiança que estava em vigor. Registre o resultado da troca, a identidade da função ou sessão e sua expiração. Registre o contexto de permissões efetivas pertinente à ação pretendida. Registre a decisão do recurso e a requisição. Por fim, registre uma observação do destino feita em instante separado. Nomes de conta, identificadores de recursos e valores podem continuar protegidos; o objetivo não é publicar credenciais, mas manter as conexões entre as decisões.

Fontes

  1. GitHub Docs — Configurar OpenID Connect em provedores de nuvem
  2. GitHub Docs — Referência de OpenID Connect
  3. GitHub Docs — Configurar OpenID Connect na Amazon Web Services
  4. GitHub Docs — Usar OpenID Connect com workflows reutilizáveis