Making your product rotation-friendly is a great way to demonstrate your security-first mindset. As well, helping your customers stay secure is a simple investment in your own operational stability.
Be sure to check out the automated rotation overview before diving in.
To support rotation, your product must allow a customer to programmatically create and revoke a secret. It must also allow the customer to have more than one active instance of the secret at a time. This provides the minimal requirements for rotation, though there are additional features that can make this process even more secure.
At any time, a customer should be able to have at least two instances of a secret. More than two can make adopting rotation simpler but is technically not required.
Secret instances should be able to be created and deleted via API
Duplicating or copying an existing secret is especially helpful when a secret can be assigned scopes or roles; it alleviates the need to duplicate scoping in 3rd-party tools like Doppler.
If your secret has a layer of abstraction, such as underlying keys with GCP Service Accounts or AWS IAM Users, then roll support can greatly simplify the process. The secret itself - i.e. the Service Account - contains the permissions, policies, and/or scoping while the underlying keys are how the secret is used.
Example: GCP IAM
Supporting OAuth in conjunction with secret-based auth (such as a token) eliminates the need for a 3rd-party like Doppler to posses long-lived secrets while still enabling customers to interact with your API in a low-latency fashion.
Allowing a secret to describe itself - including the roles / scopes it has - is another way to make onboarding new secrets simpler. The 3rd-party, such as Doppler, then no longer needs to store state about the secret that could change in your product - it can always check just-in-time.
Updated 16 days ago