Building a credential-less application with Akeyless

Background

In this series of blog posts I’m going to provide an in-depth explanation (with working examples) of how to build and maintain a credential-less application. This is a great risk reduction strategy for businesses, and that’s not even the best reason to do this! The patterns we establish here are going to solve a host of access management challenges, minimizing the effort needed for ongoing development and maintenance. By the time we’re done, granting access to development teams is going to be both easier and more secure. As the icing on the cake, the setup and configuration for all of this will be almost completely automated via Terraform, so setting up an application like this is also very simple. You can take these examples, copy and paste them, make a few minor tweaks, and have a fully setup and ready-to-go environment in no time.

Dynamic Credentials

Before we get too far though, let’s talk about what I mean by “credential-less”. Obviously credentials will still exist. What we’re really going to do is to get rid of all static credentials. Rather than relying on fixed credentials we’re going to exclusively use dynamic credentials - credentials that are generated as needed, given only to authorized users, and automatically revoked after a short time period. We’ll need a good secret manager to handle this process for us.

The underlying danger this addresses is the risk of stolen credentials. Stolen credentials are ranked as the leading cause of data breaches in many studies (see for example IBM’s cost of a data breach report for the last couple years). By building an application that simply doesn’t have credentials, we can completely negate both the most common and most dangerous route that attackers use to penetrate organizations and infrastructure.

Removing Secrets From the Environment

The other major change we’re going to make is to remove secrets from our environment. Many applications rely on pulling secrets out of the environment at boot time (whether literal environment variables or a .env file). This creates a challenge when you must change credentials, and also creates an avenue for credential theft that is being increasingly taken advantage of by supply chain attacks. Instead of storing secrets in the environment, we’re going to store references to secrets in our secret manager. As we’ll see, this has a number of advantages for both security and agility, with big wins for development teams.

Secret Management as a first class citizen

To boil it all down, what I’m really doing is promoting secret management as a first-class development requirement. After all, everyone is already doing secret management. Consider a “simple” problem: database access. Your application servers, developers, etc, all need database access. Also, since your database is in a private network, granting database access also requires granting network access. You probably also have to grant access for database migrations systems, backup processes, etc… Often these different needs result in different kinds of credentials created and stored everywhere - developer machines, .env files, environment variables, 3rd party systems, deployment systems - the list goes on and on with the end result that credentials are copied everywhere until leaked credentials and a data breach become inevitable.

By switching from static credentials to dynamically generated credentials, access management instead becomes a matter of configuration. Rather than directly giving a person or service credentials, you give them access to request credentials from the secret manager. Since all access is via short lived credentials, you can revoke someone’s access to your infrastructure by simply revoking their access to your secret manager. Even better, you can revoke access and credentials with confidence because you don’t have to worry about whether or not a particular set of credentials was re-used elsewhere: no more shared credentials used by multiple people and/or services!

Tooling

So what do we need to do this? Here’s the primary systems we’ll be using to make this happen:

1. Akeyless
2. clearskies
3. Terraform
4. AWS (ECS, Lambda, RDS)
5. Github

I’ve chosen AWS and Github simply because they are commonly used. I’ll be setting up automatic deployments, so I’ll be using Terraform to manage infrastructure deployments. I’m using Terraform rather than CloudFormation because it has better support for non-AWS resources and will work for teams that aren’t using AWS. I am going to assume that you are already familiar with AWS, Github and Terraform. I won’t go into a ton of detail about their usage, since I already have plenty to talk about and these are commonly used tools.

Akeyless is our secret manager of choice, but to be honest it isn’t really a choice, because there isn’t really any competition. It’s the only secret management tool that can do this at scale in any environment. Environment-specific tools (e.g. the AWS ecosystem) can get you close, but they miss a few details and only work if you are fully committed to a single platform. For completeness though, I will mention some alternatives - as well as their benefits and disadvantages - in the appendix.

For this demonstration, I’ll be using clearskies, a python framework I wrote that treats secrets management and dynamic credentials as a first-class citizen.

But that’s not my tool set!

It’s a good bet that these aren’t the exact tools you use. Even if you are using AWS, you may not be using the exact combination of services that I use in this example. You’re certainly not using clearskies. That’s okay though. My focus here will be less on the exact tool set and more on the general priciples and practices. These same concepts can be adapted to whatever tool set you are using. The only part of this that is really non-negotiable is Akeyless. As mentioned above, other tools can get you close to 100% coverage with dynamic credentials, but Akeyless is the only one that can get everything, do it at scale, and is easily accessible from any environment.