A secrets store is a secure location for storing your project's secrets and making them available as required to various parts of a project. This may include usage in apps, services, APIs, or deployment processes.
Almost every application is part of a larger ecosystem that connects with other services like databases, APIs, etc. Before the "Secure Secret Store" era, secrets used for connection to other services were stored in code, configuration files, initialization parameters, version control repositories, external files, databases, etc. That approach experiences "Secrets Sprawl", which refers the state in an organization where secrets are stored in many different places without access control, audit, logging, and many cases without encryption.
Secrets should not to be include in source code, nor checked into git. All sensitive pieces of configuration should be kept in a secure, managed secrets store. Benefits include:
- Centralized location for storing secrets, keys, and certificates.
- Long-term scalability of storage location.
- Automatic encryption when stored and decription when retrieved.
- Enabling automated logging when secrets are stored and used, and by whom.
- Secure access from DevOps workflows and automation as required.
- Removes dependency on direct access to secrets during development and in production.
The table below has populated a selection of tools covering similar functionality.
It is important to note that other factors may influence your choices, such as the availability of an official Azure DevOps Extension / GitHub Action that can be used in a Workflow or its ability to be used from a shell, among other things.
| Tools | Use Case | Command Line | GitHub Action | Azure DevOps Extension / Task | Service |
|---|---|---|---|---|---|
| Azure Key Vault | Securely store and tightly control access to tokens, passwords, certificates, API keys, and other secrets. | Azure CLI / PowerShell | No / Yes (via Azure CLI Action) | Azure Key Vault Task | Cloud-managed (Azure) |
| HashiCorp Vault | Securely store and tightly control access to tokens, passwords, certificates, API keys, and other secrets. | Vault CLI | Vault Secrets Action | No / Yes (via Vault CLI) | Self-managed / Cloud-managed (HashiCorp Cloud Platform (HCP)) |
| GitHub Encrypted Secrets | Securely store tokens, passwords, API keys, and other secrets for GitHub Workflows. | GH CLI | Native Support | No / Yes (via GH CLI) | Cloud-managed (GitHub) |
| Azure DevOps Secure Files | Securely store certificates, provisioning profiles, keystore files, SSH keys for Azure Pipelines. | N/A | N/A | Download Secure File Task | Self-managed (Azure DevOps Server) / Cloud-managed (Azure DevOps Services) |
The links below will direct you to implementation examples that showcase common scenarios.
- Azure Key Vault usage examples with GitHub Workflows
- Azure Key Vault usage examples with Azure DevOps Pipelines
- HashiCorp Vault usage examples with GitHub Workflows
- HashiCorp Vault usage examples with Azure DevOps Pipelines
- GitHub Encrypted Secrets usage examples with GitHub Workflows
- Secure Files usage examples with Azure DevOps Pipelines
- Azure Key Vault usage examples with Edge Kubernetes Clusters
This project welcomes contributions and suggestions. Most contributions require you to agree to a Contributor License Agreement (CLA) declaring that you have the right to, and actually do, grant us the rights to use your contribution. For details, visit https://cla.opensource.microsoft.com.
When you submit a pull request, a CLA bot will automatically determine whether you need to provide a CLA and decorate the PR appropriately (e.g., status check, comment). Simply follow the instructions provided by the bot. You will only need to do this once across all repos using our CLA.
This project has adopted the Microsoft Open Source Code of Conduct. For more information see the Code of Conduct FAQ or contact opencode@microsoft.com with any additional questions or comments.
This project may contain trademarks or logos for projects, products, or services. Authorized use of Microsoft trademarks or logos is subject to and must follow Microsoft's Trademark & Brand Guidelines. Use of Microsoft trademarks or logos in modified versions of this project must not cause confusion or imply Microsoft sponsorship. Any use of third-party trademarks or logos are subject to those third-party's policies.