Other Systems

We’ve seen how to manage access to our cloud provider, networks, and databases. The problem is that these are not the only systems you’ll need access to. Akeyless certainly has a long list of dynamic secret providers that are supported out of the box, but they obviously don’t have coverage for everything. Moreover, there will be many systems that your software will interact with that won’t have any options for automatically managing credentials, which means that using short-lived credentials is literaly impossible! So, how do we accept this reality without destroying all of our hard work?

Custom Dynamic Producers

If you regularly interact with a service that has options for automatic credential management, but which doesn’t have a dynamic producer already supported in Akeyless, then you can use custom dynamic producers to make this happen on your own. These work via webhooks! You host three endpoints of your own:

1. A create endpoint, which has the logic needed to create credentials on the destination system.
2. A revoke endpoint, which has the logic needed to revoke credentials from the destination system.
3. A rotate endpoint, which has the logic needed to rotate the credentials used to interact with the destination system during create and revoke operations.

When you create a custom dynamic producer, you give it the three endpoints, as well as a “payload” which in practice is a set of credentials to interact with the remote system. The end-user in Akeyless won’t see any of this configuration (or the payload/credentials). Instead, they just request a set of credentials from the custom dynamic producer in the same way they would from any other producer. When this happens, the custom dynamic producer invokes the “create” endpoint and passes along the payload. The “create” endpoint then goes through its own logic to generate new credentials and returns them to Akeyless with a unique identifier. Akeyless passes the credentials along to the end-user and, when the credentials are supposed to expire, will issue a call to the “revoke” endpoint along with the payload and the unique identifier for those credentials. The “revoke” endpoint then revokes the credentials. Finally, the “rotate” endpoint will be called on a pre-configured schedule (as well as on an ad-hoc basis when requested) in much the same way, and can return a new payload (e.g. new credentials) to be stored in the custom dynamic producer and replace the old ones. In this way, you can bring temporary credentials to any system that supports methods for programmatic credential management.

The fact that the payload/credentials are stored in Akeyless itself and only passed to your endpoints during a transaction allows these endpoints to be simple and stateless (as well as more secure, since authentication isn’t normally an issue). Akeyless handles proper storage of your “root” credentials, keeps track of the TTL for temporary credentials so it can issue a revoke command when needed, and also schedules your root credential rotation. As a result, managing these custom dynamic producers is surprisingly easy.

Static Secrets

Sadly, it’s inevitable that you’ll interact with systems that don’t support programmatic credential creation, or which you don’t use often enough to be worth the effort of creating/maintaining a custom dynamic producer. When this happens you don’t have any choice but to fall back on static credentials: e.g. generate an API key for the system and copy it into your secret manager!

Still, we can build on the concepts in this blog series and make this as painless as possible. Most importantly, we want to continue with the concept of allowing our application to directly fetch credentials from our secret manager. We don’t want to fall into the trap of injecting our secrets into our application’s environment, as this makes credential rotation much more difficult (since it means that we have to re-deploy our application to update its configuration).

Instead, we let our application pull secrets directly out of the secret manager, and the only thing we store in the environment is the path to the desired secret in our secret manager. One important advantage of this is that it allows developers to run the application locally without having to worry about retrieving or creating credentials for themselves. This dramatically simplifies the process of onboarding new developers and bootstrapping the application in a new environment.

In addition, this allows us to make another important step. Rather than just pulling our secrets out of the secret manager when it launches, we can build our application such that it re-fetches the secrets and retries failed calls in the event that there is an authentication failure. This allows us to at least automate the process of pushing new credentials to our systems. If we wanted to rotate a static credential, our process looks like this:

1. Generate new access credential in 3rd party system
2. Put new access credential in Akeyless, under the same path
3. Revoke old access credential from 3rd party system.

When we revoke the old credential, our systems will (presumably) fail the next time they call the external system. However, they will then automatically fetch the latest credential from Akeyless and retry the failed request. This will allow it to continue on with the updated secret without causing any downtime. This also means that we don’t have to update any developer machines with the new credentials, if they have them. Therefore, we can at least automate the process of rolling out new static secrets to everyone without any interruption, which can be a substantial time savings to many businesses.

Therefore, directly integrating our applications with our secret manager allows us to take a lot of the sting out of managing static credentials in the inevitable cases where we are stuck with them.