To Key or Not to Key: That is the Question

A look at the differences between dynamic secrets and secrets rotation

Published February 27th, 2019 by Joe Garcia

Over the past few years, whether you’re a developer, a system administrator, or a security professional, your world has changed a lot. Automation is taking over.  The application code that powers this automation often needs to access a database or to use a different protected service.  To access these protected resources the application needs to handle secrets such as passwords, SSH keys, or API keys.  These secrets need to be protected from abuse, but how?  One popular approach is to use Dynamic secrets: a technique where new secrets are created on-demand, when the application needs them. Another widely used method for securing secrets is to rotate secrets frequently. What is the difference between these two techniques?  Let’s elaborate more on each concept so that you can decide which method makes the most sense for your situation. 

Dynamic Secrets 

Most dynamic secrets solutions create a secret at the time that it is needed, and also deliver it to the application. Usually this secret is reused and set to expire after a few days.  Some dynamic secrets solutions also create a new user name or account every time a new secret is created, so the user names become dynamic too.  To access a highly-sensitive resource, privileged user accounts must be created, so the solution needs highly privileged or even root-level access. This kind of access typically requires extra audit and compliance requirements to be met.

If you frequently create and delete database users each day via your chosen dynamic secrets mechanism, then a correlated amount of more audit and log activity will be created too. With so much more audit records and user names being generated, it can quickly become harder to identify any potential malicious action in the log noise.  The more transactions that use dynamic secrets, the more difficult attribution and audit becomes.

Secrets Rotation 

One of the main differences between the dynamic secrets approach and secrets rotation is that the user name is not changed when secrets are rotated, only the secret is changed.  The key to secrets rotation is a centralized vault that encrypts and rotates secrets.  CyberArk Conjur Open Source uses this approach to secure and authenticate nonhuman access.  Conjur automatically expires and regenerates secrets and then updates the secrets in the target systems.  To update the secret on the target system Conjur uses rotators that only need enough privilege to reset the password.  This is another major difference between secrets rotation and dynamic secrets: dynamic secrets solutions require highly privileged access to create new privileged accounts, whereas rotators do not require that kind of over-privileging.

By centrally managing database user accounts, you can apply an aggressive rotation schedule that keeps the password new on a time table that you dictate.  One similarity between dynamic secrets and secrets rotation is being able to set expiration dates on secrets. For example, if you need to ensure that database secrets remain valid for only 24 hours, you can add a 24-hour rotation or lease policy for either approach.  In addition, every application can have its own unique set of credentials, regardless of which approach is used.

Conclusion   

Dynamic secrets are not the end of secrets management, they are just another approach to be used in addition to secrets rotation.  Both solutions can expire and change secrets to keep them safe.  However, in highly regulated environments creating a lot of new privileged accounts or extra audit records – as is done with some dynamic secret solutions – can be an unbearable audit burden.  Deciding which solution to use should depend on the specific needs of your environment.   

There are a number of dynamic secrets solutions on the market, but there is a lot of confusion about how they work.  Just because there’s buzz around a new technology doesn’t mean security implications have been completely considered.  Enterprises are not only accountable to their customers to provide a secure application that protects them and their information, but are also accountable to legal and internal audit and compliance requirements.

Getting Hands-On

If you’d like to see secrets rotation in action, you can get started immediately with the Conjur Open Source tutorial.  This tutorial will take you through the basics of creating a security policy, creating machine identities, and using secrets management with Conjur Open Source.  If you use Google Cloud Provider, deploying Conjur Open Source only takes one click in the GCP Marketplace.  If you get stuck, no worries, help is always available on the CyberArk Commons. 

CyberArk also has developer tools to securely provide a database user secret to an application without leaking it in source code or a configuration manifest.  If you are a developer, check out our other awesome open source tools, such as Summon and Secretless.io. These tools can help you securely deliver secrets to applications and help prevent secret leaks.