Considerations for Dynamic Secrets Management

What Are Dynamic Secrets?

Dynamic Secrets are the idea of generating credentials as needed, at the moment they are required. The concept is that credentials are issued in a randomized manner, with enough entropy that they cannot be predetermined and with enough frequency to reduce the risk of credentials being leveraged as an initial attack vector if they are leaked due to the fact that they should be rotated before the opportunity to leverage them in an attack arises. This is a common practice among Cloud platforms for Just in Time or Temporary Security credentials which are largely used for Privileged Access Management, as part of Change Management or a Break Glass procedure. Typically, a human user is given temporary local admin access to affect a task directly on an application or platform. Even though dynamic secrets are infrequently implemented on a larger scale, this principle can also be leveraged to ensure an automated secrets lifecycle for regular machine-to-machine authentication to assure rotation and revocation at a rate that is adequately adapted to the speed of the infrastructure and the risk appetite of the company. Dynamic Secrets are not without complexity, so the feasibility of implementation must be regarded with a holistic approach with the assurance that the proper resources are in place to adequately manage such a program.

Considerations

In order to maximize the efficiency and security of dynamic Secrets, automation should be a primary consideration in retrieving, revoking, and generating credentials. While dynamics help mitigate the risk of credential leakage, secrets should still not be overtly exposed. By automating these processes in a secure manner, the risk of incorrectly storing the secret is reduced nor is it visible to human eyes.

Infrastructure Speed

By nature, pipelines and containers are leaky and Secrets are easily exposed with minimal effort. While there is no direct link, there appears to be a correlation between the ephemerality of the underlying infrastructure and the lack of confidentiality regarding sensitive information. For example, when leveraging Kubernetes, the Kubernetes native secret is simply base 64 encoded and placed on an unencrypted file. This leaves the Secret vulnerable, particularly if it is reused for a long duration, which is typically the case of a certificate, for example. This is susceptibility is further compounded by the highly complex, configurable nature of these technologies and a propensity for human error.

Tooling

When implementing dynamic secrets, there are several technical possibilities depending on the underlying needs, infrastructure, and feasible overhead.

Cloud Native

All of the major cloud platforms are equipped with their own flavor of a key vault which can be programmatically accessed via APIs. These key vaults allow for access or restriction based on designated roles and identities, whether they are human or machine. Platform specific identities can then be given authorization for bilateral or unilateral communication, depending on the requirement and the permissions scoped based on the need of the workload. The advantage to this is that the identities are issued and managed by the platform, making it convenient and relatively straightforward to establish a Zero Trust architecture scoped to Role Based Access Control.

Cloud Agnostic

While there are limited possibilities on the market currently that cater to dynamic secrets, both Hashicorp Vault and Akeyless offer products that manage a wide breadth of use cases for multi and hybrid cloud. The benefit of independent secrets management tools, in addition to avoiding vendor lock-in, is the assurance that dynamic secrets are properly implemented and easily configurable. By leveraging a cloud agnostic solution, the frequency of rotation can be increased, which is a significant advantage when matching the speed of a Secrets Management program to an ephemeral ecosystem, such as containerized workloads, serverless, or CI/CD pipelines.

Risk Considerations

By incorporating security into the development process, the Protect cycle is shortened and remediation can be expedited. But, as with all Risk profiles, there is a balance between what is reasonable and what may be ideal. In order to fully assess the optimal frequency of Secret generation, there are multiple factors which must be taken into account.

Enterprise Maturity

As with any DevOps oriented process which embraces the integration of security, technology and tooling are not the only considerations. For successful adoption, people and the overall maturity must be addressed. While Dynamic Secrets are gaining traction, the complexity and lack of best practice guidance may hinder adoption. Companies should be reasonably certain that standardized processes, such as deployments, requiring Secrets are automated and can sustain the required I/O with a minimal reduction in service speed. It is also imperative that the Secrets integration process itself has been automated to ensure that rotated credentials can be acquired and integrated without jeopardizing availability.

What is the magic solution

As always, it depends. With all new adoptions and program changes, success is determined by multiple factors. In the case of building a Secrets Management program which leverages dynamic credentials, while tooling is critical, automation and mindset are equally important in the success of the program. The first step in moving to dynamics is an objective assessment of capabilities, requirements, and underlying infrastructure. Once these requirements have been assessed and an ideal future state identified, it may be beneficial to instantiate a gradual migration towards dynamics by first ensuring proper secrets hygiene and the implementation of a Secrets Management program.

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store