Well-Architected Framework
Rotate secrets
Secret rotation is the process of updating the secret value of a static secret, such as a password or API key. Modern security practices recommend the use of multi-factor authentication (MFA) for users and services. However, not all services support MFA, leaving a secret as the lone method of authentication. When a service does not support MFA, regular secret rotation ensures the secret is not compromised.
Static secrets are long-lived credentials that are manually provisioned and used across teams or services. When you manually provision secrets, you need to create a process to manage and rotate the secrets.
Because teams and applications rely on the secret providing access to a target service, you should develop a rotation strategy to ensure uninterrupted access to the service.
Why should you rotate secrets?
Rotating static secrets that do not support additional authentication methods is an important part of a defense in-depth strategy. If one of your secrets becomes compromised, your organization is at risk of exposing data to unauthorized users and other threats such as ransomware. If you wait until a secret is compromised, the damage to your organization has likely already occurred.
HashiCorp Vault helps you manage the secret rotation process. Vault usually stores static secrets in a key/value (KV) secrets engine.
Rotate static secrets stored in Vault
Specific rotation strategies are highly dependent on the source of the secret, the application consuming the secret, and your service level objectives (SLO) for the application. Some applications support hot reloading of secrets when they change, others will require a restart of the application.
Since most services will rely on an existing secret, rotating static secrets is similar to performing blue/green application updates. In blue/green (link to b/g deployments?) you run the current version of an application, which is the blue version. When there is a new version of the application, you deploy the new version of the application to a second environment alongside the current (blue) version of the application. The new application version is referred to as the green version. Once you test and validate the green deployment, you direct traffic to the new (green) version of the application. If an error occurs, you can move traffic back to the stable blue version. Once you move all traffic to the new version, you decommission the previous version. This process repeats every time you upgrade the application to a new version.
To rotate static secrets, mirror this concept with a secret for the current version, and a separate secret for the new version. Store the current version of a secret at the path /dev-secrets/blue/creds. The secret stored in the /dev-secrets/blue/creds represents the current version of the secret used by your applications. When it is time to rotate (change) the secret, create or request a second secret and store the new version of the secret at the path /dev-secrets/green/creds.
You then update one or more services in your application to use the new secret. When the service successfully connects to the target using the new secret, continue rolling out the new version of the secret and decommission the previous secret from both Vault and the secret source.
HashiCorp resources:
External resources:
Next steps
In this section of how to Secure secrets, you learned about how to rotate secrets in your organization. Rotating secrets is part of the Secure systems pillar.