Humans and machines use secrets throughout the value stream of building and operating software. The build pipelines need secrets to interface with secure infrastructures such as container registries, the applications use API keys as secrets to get access to business capabilities, and the service-to-service communications are secured using certificates and keys as secrets. You can set and retrieve these secrets in different ways. We've long cautioned developers about using source code management for storing secrets. We've recommended decoupling secret management from source code and using tools such as git-secrets and Talisman to avoid storing secrets in the source code. We've been using secrets as a service as a default technique for storing and accessing secrets. With this technique you can use tools such as Vault or AWS Key Management Service (KMS) to read/write secrets over an HTTPS endpoint with fine-grained levels of access control. Secrets as a service uses external identity providers such as AWS IAM to identify the actors who request access to secrets. Actors authenticate themselves with the secrets service. For this process to work, it's important to automate bootstrapping the identity of the actors, services and applications. Platforms based on SPIFFE have improved the automation of assigning identities to services.
We've long cautioned people about the temptation to check secrets into their source code repositories. Previously, we've recommended decoupling secret management from source code. However, now we're seeing a set of good tools emerge that offer secrets as a service. With this approach, rather than hardwiring secrets or configuring them as part of the environment, applications retrieve them from a separate process. Tools such as Vault by HashiCorp let you manage secrets separately from the application and enforce policies such as frequent rotation externally.
