Posted by Jeremy Hess
March 16, 2021
In their 2019 report Remove Standing Privileges Through a Just-in-Time PAM Approach, Gartner suggested that:
“The existence of privileged access carries significant risk, and even with PAM tools in place, the residual risk of users with standing privileges remains high. Security and risk management leaders engaged in IAM must implement a zero standing privileges strategy through a just-in-time model.”
Let’s take a look at what this means, and why it is necessary.
Secrets Management is Just the Beginning
Digital authentication credentials that grant privileged access to systems and data, known as secrets, are at the foundation of any workload environment, whether legacy or cloud based. These credentials, such as encryption keys, tokens, and SSH certificates, enable components to communicate over trusted and secure connections.
A natural consequence of secrets being widely used is that they end up being stored in multiple locations, many of which are not secure. This phenomenon of secret sprawl is both a security risk, as well as a logistical and administrative nightmare.
The key to preventing secret sprawl is effective secrets management. A secrets management platform like Akeyless Vault enables you to centrally manage and protect secrets across your DevOps environment in a single, secure vault.
The Problem with Static Secrets
While secrets management platforms effectively centralize and encrypt the secrets they store, this only solves part of the problem. Static secrets have inherent shortcomings, including:
- Static secrets tend to leak. For example, plain-text credentials may be included in application source code, recorded in application logs, or stored in configuration files. The more widely a secret is used, the more vulnerable it becomes.
- Static secrets often provide persistent privileges across multiple systems, otherwise known as standing privileges. In the wrong hands, a leaked secret can provide hackers with broad access to your infrastructure, 24 hours a day, seven days a week.
The Solution: Dynamic Secrets
Dynamic secrets were specifically created to address these limitations of static secrets. But first, what are they? Dynamic secrets are ephemeral, temporary credentials that are generated on-demand to provide a client with access to a resource for a limited period of time, with a limited set of permissions.
For example, a Kubernetes container (client) spins up and requires access to a database. Instead of authenticating using a fixed database account, the container is given temporary credentials that are created on the spot and deleted automatically after a predefined amount of time.
How Dynamic Secrets Help
By design, dynamic secrets are never stored, making them less vulnerable to attack. Even if a dynamic secret is compromised, it is effectively useless by the time a cybercriminal is able to use it.
Dynamic secrets provide access that is created just-in-time (instantly, on demand), and has just enough privileges (least privilege) to complete a specific task. If static secrets provide standing privileges, dynamic secrets provide the total opposite – zero standing privileges, or ZSP. Clients have privileged access to a resource with the minimum rights they need to accomplish a specific task, for the minimum time required. Especially for ephemeral machine-to-machine operations, this could be for just a few seconds!
Just-in-Time access with dynamic secrets is also a great enabler for human-to-machine interactions, such as Zero-Trust Remote Access and Next-Generation Privileged Access Management. Look out for upcoming posts that explain how!
Dynamic Secrets with Akeyless Vault
Akeyless Vaultless® Platform enables you to easily implement dynamic secrets using predefined connectors for many different platforms, including AWS, MySQL, and Kubernetes. Minimal configuration is all that is needed for Akeyless to automatically create and delete temporary credentials.
Good to know: As a SaaS, we cannot connect to resources in your private network. All communication with these resources is filtered through the Akeyless API Gateway.
Let’s see how it’s done.
Configuring a Dynamic Secret
For administrators, configuring a dynamic secret is as straightforward as:
- Select the target (database, AWS account, and so on).
- Provide target-specific connection details (such as an IP address and port or server name) and superuser credentials authorized to create and delete temporary credentials. If Zero-Knowledge is configured, Akeyless is blind to these credentials (including the superuser credentials) and cannot access the resource without you.
- Define the exact roles and privileges the temporary credentials will have.
- Define the Time to Live (TTL) that determines when the temporary credentials are deleted.
Coming soon, Custom Dynamic User creation will extend the extensive list of resources for which you can create dynamic secrets to include ANY platform, such as an external API or network device.
Requesting Credentials
For clients (i.e. your applications), getting temporary credentials is as effortless as requesting the secret using the CLI, or one of the many supported SDKs and plugins. The same request is sent irrespective of the resource for which the secret is being requested.
- A client requests a dynamic secret.
- Akeyless communicates with the resource to get the new credentials.
- Akeyless provides the credentials to the client.
The Bottom Line
Dynamic secrets provide a more secure alternative to traditional, static secrets by enabling you to achieve zero-standing privileges using a just-in-time model that provides users with ephemeral credentials for specific resources. Akeyless provides you with a unified interface from which you can generate dynamic secrets for multiple types of resources, and utilize the Akeyless Vault platform’s access control, encryption, and comprehensive audit logging capabilities.
Want to know more about Akeyless? Get a demo today! Or just register for free and try it out.
