Secret Rotation

Companies constantly work with sensitive data and private services that teams need for their workflows. They have to protect those resources while minimizing the impact on productivity. Secrets management is a job every business needs to do.

Secrets are all the passwords, certificates, keys, and other methods used to authenticate and authorize access to these resources. Managers need them to lock down access to only sanctioned users in the organization.

One strategy commonly deployed by DevSec professionals is secret key rotation. If a credential, password, or key is ever compromised, then the company must rely on the ability to revoke it and prevent further access. Rotation regularly ensures that stolen keys cannot be used for long.

What Is Secret Rotation?

You will inevitably need to transfer secrets from one service to another, but how do you do so in a secure way? By default, credentials are usually hardcoded into the services, presenting a few issues:

• It’s difficult to get up and running again in case configuration files are lost, as you likely won’t know where the secrets came from.
• It’s a headache to change it. What will you do if the credential is ever compromised?
• It requires too much work from the staff.

The solution is to use automated secret manager rotation. You’re probably familiar with it if you’ve ever used 2-factor authentication. Rotation works by keeping two versions of the same secret valid at the same time.

The following steps occur during a rotation:

• The system creates a new secret, resulting in three valid ones.
• A verification is performed to ensure all secrets work.
• The oldest one is removed, and we’re back at 2 valid secrets again.

The services only need to understand that the expiring secret is about to go invalid and must be able to refresh access when it does.

Rotation’s Place in the Lifecycle of a Secret

Secrets are designed to be ephemeral and flexible. All of them follow a similar lifecycle as a result: creation, rotation, and expiration.

• Creation: The secret is generated either manually by a user or automatically by an application. An example would be writing up a new password for a user account. Automatic creation is preferred since human-written secrets are often easy to hack into.
• Rotation: Changing secrets regularly on a schedule is heavily recommended and often required if your business follows security standards like PCI DSS (which mandates up to a 90-day rotation cycle).
• Expiration: Being able to revoke access in the event of a security breach, detection of suspicious activity, or the leaving of an employee is critical and consequently required for certain security standards like NIST 800-53.

Being an essential step in the lifetime of a secret, rotation is available through the enterprise key managers of multiple platforms from AWS to Azure to Kubernetes.

Examples of Implementation

Credential rotation is an essential component of enterprise-grade cybersecurity. It’s practically mandatory for legal compliance as well, hence why so many cloud secrets management platforms support it.

The process sounds complicated, but thankfully a DevOps secrets vault handles all of it for you if your system is compatible. Examples of platforms with secret managers that support rotation include the following.

Amazon Web Services

Keep in mind that some businesses only support a one-user, one-password setup. If you’re rotating secrets with AWS for instance, look to the AWS documentation for guidance.

AWS also allows the client to select the frequency of automatic rotation by a certain number of days. This feature is necessary because changing credentials can cause disruptions and unexpected behavior when working with the application, and knowing the timing helps.

Kubernetes

Google’s implementation of Kubernetes, known as the Google Kubernetes Engine (GKE), allows rotation of cluster credentials, as well as IP rotation if necessary. Rotating secrets with Kubernetes is a natural aspect of working with containerized applications. Check the official documentation here.

Azure

Rotating secrets in Azure is also possible. One implementation involves generating new secrets and updating the DevOps configuration files accordingly to rewrite over the old ones. To prevent potential problems, the system always updates each application and notifies the relevant users before retiring the old credentials.

Akeyless Rotated Secrets

Akeyless Vaultless® Platform offers a Rotated Secrets option that enables users to protect credentials for privileged-user accounts – such as an Administrator account on a Windows server, a root account for a Linux server, or an Admin account for a network device – by resetting its password.

Akeyless generates a new password, resets it on the target machine, and stores the updated secret value so that it can be retrieved when required. To do this, you define a rotated secret to automatically update the password at defined intervals, or manually trigger a password update from the CLI or from the Akeyless Console.