Conceito e mecanismo
O GITHUB_TOKEN tem permissões definidas pelo contexto e pela configuração efetiva. Ao declarar permissões específicas, as omitidas ficam none. Concede apenas as operações necessárias ao job que as executa e verifica controlos adicionais do recurso de destino. Um reusable workflow não pode elevar as permissões recebidas do caller. A passagem de secrets também tem um contrato: se A passa um secret a B, isso não o disponibiliza automaticamente a C. Cada ligação deve declarar o que precisa e estar autorizada a receber. Separar build, publicação e promoção pode tornar estas necessidades mais claras, desde que as fronteiras também estejam refletidas na execução real.
Aplicação guiada
Num incidente fictício após rotação, considera quando cada valor foi lido. Secrets de organização e repositório são lidos quando o run entra em fila; secrets de environment são lidos quando o job que o referencia começa. Uma rotação não implica releitura contínua em cada linha do shell. Para produção, quando o plano suporta required reviewers, o job aguarda a aprovação antes de aceder aos secrets do environment. Confirma que o job referencia efetivamente esse environment e que as políticas de branches são adequadas. Na passagem para APS, documenta quem aprova, como se recupera uma execução bloqueada e que evidência distingue uma falha de autorização de uma credencial expirada.
A concede só contents: read; C pede packages: write: corrigir o contrato no caller autorizado, sem esperar elevação no chamado.
Armadilhas comuns
Secrets transitivos; output como cofre; nome production como gate; rotação como releitura imediata; write-all como diagnóstico.
Tópicos relacionados: Eventos, filtros e dependências · Dados, outputs e rede dos services · Reutilização, artifacts e diagnóstico
Regista âmbito, momento de leitura, destinatário e aprovação de cada acesso.
Referência: Secret scope and read time · GH-200 skills measured January2026;study guide updated2026-02-05