Proteger segredos no Azure Pipelines
Azure DevOps Services | Azure DevOps Server 2022 | Azure DevOps Server 2020
Este artigo mostra as práticas recomendadas para proteger segredos no Azure Pipelines. Um segredo é qualquer coisa a qual você queira controlar rigidamente o acesso, como chaves de API, senhas, certificados ou chaves de criptografia.
O Azure Pipelines não gera valores de segredos. No entanto, talvez seja necessário adicionar um segredo a um pipeline para armazenar dados confidenciais como uma chave de API. Para saber mais sobre como definir variáveis de segredo, consulte Definir variáveis de segredo.
Não use segredos se outro método estiver disponível
O melhor método para proteger um segredo não é ter um segredo em primeiro lugar. Verifique se o pipeline pode usar um método diferente do uso de um segredo para executar uma tarefa.
- Use conexões de serviço:
- Ao direcionar o Azure ou outros serviços, use conexões de serviço em vez de gerenciar segredos em variáveis.
- As conexões de serviço permitem que você se conecte com segurança a serviços externos sem expor informações confidenciais diretamente na configuração do pipeline.
- Para obter mais informações, consulte Gerenciar conexões de serviço e Conectar-se ao Microsoft Azure com uma conexão de serviço do Azure Resource Manager.
Usar identidades gerenciadas:
- Considere usar identidades gerenciadas em vez de lidar diretamente com segredos.
- As identidades gerenciadas permitem que seus aplicativos e serviços autentiquem a segurança com os serviços do Azure sem exigir credenciais explícitas.
- Você pode usar identidades gerenciadas para acessar outros serviços do Azure.
Tarefa da CLI do Azure:
- Se você estiver usando a tarefa da CLI do Azure, em seu pipeline, considere usar a configuração para acessar os detalhes da
addSpnToEnvironment
entidade de serviço no script sem passar segredos explicitamente.
- Se você estiver usando a tarefa da CLI do Azure, em seu pipeline, considere usar a configuração para acessar os detalhes da
Para obter mais informações, consulte Usar entidades de serviço e identidades gerenciadas
Usar variáveis de segredo
Nunca armazene valores confidenciais como texto não criptografado em um arquivo .yml do Azure Pipelines.
Variáveis de segredo podem ser usadas para informações privadas, como senhas, IDs e outros dados de identificação que você não gostaria de expor em um pipeline. Recomendamos que você defina variáveis secretas com o Azure Key Vault. Você também pode definir variáveis secretas na interface do usuário ou em um grupo de variáveis. Não recomendamos o uso de um comando de registro para definir uma variável secreta. Quando você define um segredo com um comando de log, qualquer pessoa que possa acessar seu pipeline também pode ver o segredo.
As variáveis de segredo são criptografadas e podem ser usadas em pipelines sem expor seus valores. Embora os valores não sejam expostos, nunca ecoe segredos como saída e não passe segredos na linha de comando. Em vez disso, a recomendação é mapear os segredos para variáveis de ambiente.
Ao criar um segredo, siga as diretrizes de nomenclatura de variáveis e certifique-se de que o nome do segredo não divulgue informações confidenciais.
Limitar o acesso a variáveis de segredo
Para limitar o acesso a segredos no Azure DevOps, siga estas práticas recomendadas:
- Armazenar seus segredos no Azure Key Vault. Com o Azure Key Vault, você pode usar o modelo de controle de acesso baseado em função do Azure para limitar o acesso a um segredo ou grupo de segredos.
- Definir variáveis de segredo na interface do usuário em um pipeline. As variáveis secretas definidas na interface do usuário das configurações de pipeline têm como escopo o pipeline em que estão definidas. Assim, você pode ter segredos visíveis apenas para os usuários com acesso a esse pipeline.
- Definir segredos em um grupo de variáveis. Grupos de variáveis seguem o modelo de segurança da biblioteca. Você pode controlar quem pode definir novos itens em uma biblioteca e quem pode usar um item existente.
Não escreva segredos em logs
O Azure Pipelines tenta limpar segredos dos logs sempre que possível, mas não é infalível. Evite ecoar segredos no console, usá-los em parâmetros de linha de comando ou registrá-los em arquivos. Tenha cuidado ao usar comandos da CLI do Azure que geram informações confidenciais. Use o None output format
e, se precisar recuperar um segredo de uma chamada da CLI do Azure, Use none output format and retrieve security information to a secret variable
o .
Não use dados estruturados como segredos
Evite usar formatos de dados estruturados como JSON, XML ou YAML, para encapsular valores secretos, incluindo caracteres de controle, \r
como retorno de carro e alimentação de linha.\n
Em vez disso, crie segredos individuais para cada valor sensível. Essa abordagem garante melhor precisão de redação e minimiza o risco de expor dados confidenciais inadvertidamente.
Auditar a forma como os segredos são tratados
Para auditar como os segredos são usados no Azure Pipelines, siga estas práticas recomendadas:
- Examinar o código-fonte: examine o código-fonte do repositório que hospeda o pipeline. Para garantir que os segredos sejam tratados corretamente, verifique todas as tarefas usadas no pipeline. Por exemplo, verifique se os segredos não são enviados inadvertidamente para hosts não intencionais ou impressos explicitamente na saída de log.
- Inspecionar logs de execução: depois de testar entradas válidas e inválidas, exiba os logs de execução do pipeline. Certifique-se de que os segredos sejam redigidos corretamente e não expostos. Às vezes, erros em comandos ou ferramentas podem vazar segredos inadvertidamente em logs de erros. Embora o Azure Pipelines tente limpar segredos dos logs, a revisão manual ainda é essencial.
Auditar e girar segredos
Para auditar e alternar segredos, siga estas práticas recomendadas:
- Revise os segredos registrados: avalie periodicamente os segredos registrados em seus pipelines. Confirme se eles ainda são necessários e remova os que não são mais necessários, o que ajuda a reduzir a desordem e os possíveis riscos de segurança.
- Alternar segredos: alterne regularmente os segredos para minimizar a janela de tempo durante a qual um segredo comprometido pode ser explorado. Ao alterar os segredos periodicamente, você aumenta a segurança.
- Escolha o método de autenticação correto
- Tipos de segredos usados:
- Tokens de acesso pessoal (PATs): esses tokens são usados para autenticação. Siga as práticas recomendadas de segurança ao escolher o método de autenticação correto. Você pode gerenciar PATs usando a API REST.
- Variáveis secretas: use variáveis secretas para armazenar com segurança informações confidenciais, como chaves de API, senhas ou outras credenciais em seu pipeline.
- Segredos do Azure Key Vault: use o Azure Key Vault para armazenar e gerenciar segredos com segurança.
- Conexões de serviço: essas conexões de serviço permitem que seu pipeline se conecte a serviços externos (por exemplo, Azure, GitHub, Docker Hub). Garanta a configuração adequada e o tratamento seguro dos segredos de conexão de serviço.
- Tipos de segredos usados:
Usar modelos YAML
Em vez de incluir scripts embutidos com parâmetros secretos diretamente no YAML do pipeline, use modelos. Essa abordagem aumenta a segurança abstraindo informações confidenciais do pipeline principal.
Para implementar essa abordagem, crie um arquivo YAML separado para o script e armazene esse script em um repositório separado e seguro. Em seguida, você pode fazer referência ao modelo e passar uma variável secreta em seu YAML como um parâmetro. A variável segura deve vir do Azure Key Vault, de um grupo de variáveis ou da interface do usuário do pipeline. Para obter mais informações sobre como usar modelos, consulte a Referência de uso do modelo.
Limitar segredos com políticas de branch e permissões de grupo variável
Para garantir que os main
segredos estejam vinculados ao branch e não acessíveis a branches aleatórios, você pode usar uma combinação de permissões de grupo de variáveis, inserção de trabalho condicional e políticas de branch.
Com as políticas de branch, você pode impor políticas de validação de build que permitem apenas builds do branch principal. Em seguida, você pode usar permissões de grupo de variáveis para garantir que apenas pipelines autorizados tenham acesso aos segredos armazenados em seu grupo de variáveis. Por fim, você pode usar uma condição em seu pipeline para garantir que o grupo de variáveis só possa ser referenciado por um push para o main
branch.
jobs:
- job: ExampleJob
condition: and(succeeded(), eq(variables['Build.SourceBranch'], 'refs/heads/main'))
pool:
vmImage: 'ubuntu-latest'
steps:
- script: echo "This runs only for the main branch"
displayName: 'Conditional Step'
variables:
- group: your-variable-group-name