Separe automação e administração pessoal
Um pipeline de API de relatórios precisa selecionar um artefato aprovado e invocar uma ação de versão controlada. Isso não exige automaticamente criar usuários, alterar cobrança ou ler todos os segredos da aplicação. Comece com um inventário de permissões e um ambiente de teste protegido; mantenha credenciais fora de documentos, repositórios e logs de exemplo.
O acesso humano de recuperação deve permanecer separado para que revogar uma credencial de implantação não remova o único caminho de investigação. Identifique um mantenedor autorizado e verificação independente do host. Uma segunda chave irrestrita é outra credencial, não um papel mais restrito.
Descreva a operação permitida com precisão
| Capacidade | Necessário? | Fronteira |
|---|---|---|
| Ler artefato aprovado | Sim | Repositório/versão específico |
| Invocar ação de versão | Sim | App e ambiente fixos |
| Ler todos os segredos de runtime | Evitar | Identidade de runtime controlada |
| Modificar usuários ou política SSH | Não | Administração separada |
| Alterar configuração do fluxo de trabalho | Não para identidade de runtime | Revisão de repositório protegido |
| Excluir backups | Não | Permissões de recuperação separadas |
Valide as entradas da ação de versão. Um comando restrito que concatena texto arbitrário em um shell privilegiado ainda permite trabalho não intencional. Revise o comportamento do wrapper, caminhos graváveis e confiança em artefatos em conjunto. Privilégios amplos de sudo ou acesso ao socket do Docker podem derrotar a fronteira pretendida.
Trate edições de fluxo de trabalho como acesso a credenciais
Alguém capaz de alterar etapas confiáveis de fluxo de trabalho pode usar ou expor suas credenciais. Revise permissões de repositório, ambientes de implantação protegidos e quais eventos executam jobs privilegiados. Mantenha credenciais de produção longe de código não confiável de pull request. Dê a um token de fluxo de trabalho apenas as permissões que sua tarefa precisa.
O GitHub recomenda fixação de commit SHA de comprimento total para seleção imutável de ações. Revise a ação selecionada e atualizações posteriores; uma tag de versão pode se mover. Evite inserir dados de eventos não confiáveis diretamente em código shell inline. Mascarar valores de segredos conhecidos não é uma garantia contra divulgação por meio de transformações, logs ou artefatos.
Referência técnica: Uso seguro do GitHub Actions.
Use tempo de vida curto quando o destino suportar
O OpenID Connect pode permitir que um destino suportado troque a identidade do fluxo de trabalho por uma credencial de curta duração. Configure verificações de confiança para o repositório, branch ou ambiente pretendido e audiência. Isso não é um substituto universal para SSH nem um recurso fornecido pelo frontend PrivacyNodes atual.
Se sua implantação usa SSH, revise as opções de chave autorizada do pacote instalado. Um comando forçado sozinho não proíbe encaminhamento; as restrições devem cobrir os caminhos de acesso pretendidos e ainda invocar uma operação de versão segura. Teste em um ambiente separado. Preserve o acesso administrativo e de recuperação funcional ao alterar a autenticação, e verifique uma nova conexão independente antes de remover o método antigo.
Referência técnica: OpenID Connect do GitHub Actions · Formato OpenSSH authorized_keys.
Teste trabalho permitido e proibido
Verifique se a identidade consegue selecionar o artefato pretendido, invocar a versão e obter um resultado útil. Depois teste seus limites: segredos de outra aplicação, alterações de arquivos não relacionadas e administração arbitrária devem estar indisponíveis. Inclua caminhos de artefato e argumentos que o wrapper deve rejeitar.
Registre identidade, escopo, expiração quando aplicável, mantenedor aprovador e local das evidências de auditoria. Mantenha referências de armazenamento em vez de valores de credenciais. Se um teste só funcionar após conceder ampla administração, reveja a tarefa de versão em vez de silenciosamente torná-la o papel permanente.
Ensaie revogação e uma versão com pipeline quebrado
Prepare uma substituição com o escopo revisado, verifique uma implantação de teste, altere o pipeline e revogue a identidade antiga. Confirme que a credencial substituída falha e que não resta duplicata em outro fluxo de trabalho. Adicionar uma nova chave sozinho não remove o acesso anterior.
Documente como um mantenedor autorizado interrompe a implantação e recupera quando o CI está indisponível. Vincule esse procedimento ao registro de versão e inventário de recuperação. Uma credencial restrita limita a autoridade pretendida; ela não torna um artefato malicioso inofensivo.
Referências oficiais
A documentação foi revisada para este artigo. Os exemplos são exercícios de planejamento, não comandos testados em um servidor PrivacyNodes. Verifique a documentação da sua versão instalada.