AWS Access

In our last blog post we saw how to grant developers access to the database from their local machine. Similarly, developers may need AWS access (either programmatic or to the console). Consider running terraform: we would certainly prefer to have all changes to production flow through our pipelines and roll out automatically (otherwise mistakes will happen). However, giving developers the option to run terraform plan locally can save a lot of time if otherwise they have to push changes up and wait for a pipeline to run to see the results of their changes.

Programmatic Access

Again, we can solve this problem easily. I’ll even keep this part short because everything we will do to solve it uses things we’ve already discussed. After all, our developers already have SAML access to Akeyless and Akeyless can create AWS credentials with admin access. This means that our developers can run a full terraform plan/apply cycle if they want. If we don’t want to give developers access to deploy changes directly to production, then we can create a new AWS producer that grants credentials with read-only access. This will allow our developers to only execute a terraform plan step.

While a developer could use the Akeyless console to fetch AWS credentials, this is not very convenient. As a simpler method, they can install the Akeyless CLI. Once installed, the first step is to configure the CLI for SAML login:

akeyless configure --access-type=saml --access-id=[YOUR_SAML_ACCESS_ID_HERE]

Then you are ready to create credentials! The following commands will let you generate credentials from an AWS producer and then configure the AWS CLI to use them. This will allow you to run terraform locally. Note that these commands require the use of the jq tool. Don’t forget to edit the second line to provide the path to your AWS dynnamic producer:

unset AWS_ACCESS_KEY_ID AWS_SECRET_ACCESS_KEY AWS_SESSION_TOKEN
STS_CREDENTIALS=$(akeyless --name get-dynamic-secret-value /path/to/dynamic/producer)
export AWS_ACCESS_KEY_ID=$(echo $STS_CREDENTIALS | jq -r ".access_key_id")
export AWS_SECRET_ACCESS_KEY=$(echo $STS_CREDENTIALS | jq -r ".secret_access_key")
export AWS_SESSION_TOKEN=$(echo $STS_CREDENTIALS | jq -r ".security_token")
unset STS_CREDENTIALS

# verify that it worked!
aws sts get-caller-identity

Note that I’m using environment variables, rather than the AWS credential file. This works fine but means that if you switch to a new terminal/tab/session/whatever, you’ll have to execute the commands again. The other alternative is to dump the credentials into the ~/.aws/credentials file. I don’t give an example of that here because there are many different ways to use the credentials file (including setting up multiple profiles if desired), so the best approach there depends on your preference for interacting with AWS services.

Console Access

What about AWS console access? Being able to run terraform locally is nice, but chances are your developers are going to want to login to the AWS console as well. Of course, AWS has many ways to grant console access via SAML, so Akeyless isn’t required here in order to grant access securely. However, you might not want to use AWS directly for this. After all, Akeyless is allowing us to centralize and manage access from one place. It may not be worth it to break that pattern for AWS console access.

If you want to let Akeyless be in charge of everything, then you can simply create an AWS dynamic producer that grants console access. However, this doesn’t immediately lend itself to an easy workflow. Developers would have to generate AWS credentials from the Akeyless UI and then copy and paste them to login to the AWS console. This (among other things) is what the Secure Remote Access product from Akeyless is designed to fix. It will automate the process of developers leveraging their Akeyless access to login to the AWS console. It will also allow for detailed controls like session recording and session termination. Finally, it can simplify access to other systems as well. For instance, rather than using clearskies to connect to the database using SSH certificates and dynamic database credentials, the secure remote access portal can handle all of that for you, allowing you to connect directly to your database from a browser using a GUI, without needing any additional tooling installed locally.

I’m not going to go into further detail on the secure remote access portal since this blog series is already too long! Still, if the access methods outlined in this blog post work well for you then you’ll definitely want to check out secure remote access to see if it will benefit your team.