Managing AWS Credentials
Now it’s time to implement a key ability of Akeyless: managing AWS credentials. This is done via AWS targets and producers. If you recall, these all live on the Gateway, which is why we’re only doing this now.
Strategies for Akeyless access (aka: targets)
We will create a producer on our Gateway that will manage AWS access for us, but to do that the producer itself first needs AWS access! Akeyless supports two main strategies for its own AWS access: by giving the producer IAM user credentials or by attaching the necessary permissions to the underlying Gateway infrastructure. Either strategy works for our purposes. Giving Akeyless IAM credentials would result in a set of static credentials, but Akeyless allows us to easily configure rotation for these credentials. The advantage of giving the producer IAM credentials is that it can more easily manage AWS access for multiple AWS accounts, or allow you to manage AWS credentials even if your Gateway isn’t hosted in AWS. The disadvantage, of course, is the fact that we need actual credentials.
In either case we configure the producer’s access to our AWS account with a target. A target contains everything Akeyless needs to access a system and manage credentials. For a database, this might be the ip/domain of the database plus database credentials, for AWS this might mean IAM credentials, etc… In the case of the AWS target it also has an option to “use own credentials” which tells the producer to connect to AWS using the permissions attached to the underlying infrastructure (e.g. the task execution ARN). For this example we’re going to use IAM credentials to manage access, so we’ll need to:
- Create an IAM user with permission to manage its own access keys (for rotation)
- Create an access key for the user
- Use this access key to create an AWS target in Akeyless
- Deploy a rotator in Akeyless, point it to the AWS target, and configure it to rotate every day
This will give us the ability to make producers for managing temporary AWS access.
Strategies for Credential Management (aka: producers)
There are also two ways to manage temporary AWS credentials using an AWS producer. The first option is to have the AWS producer create an IAM user, attach permissions to it, pass along the IAM credentials to the requesting user/service, and delete the IAM user when the credentials are supposed to expire. Alternatively, it can execute a standard assume role operation and then hand out the resulting STS credentials. In terms of the differences. There are some practical differences created by this choice of strategy:
Credential Lifecycle With assume role, Akeyless doesn’t actually control the credential lifecycle - AWS does. Akeyless will normally let you extend or revoke individual credentials/sessions, but AWS does not actually expose these options for STS credentials. As a result, extending or revoking a session in Akeyless won’t actually do anything if you use an assume role flow.
Credential Readiness A side effect of AWS’ eventual consistency model is that AWS will actually issue IAM credentials before they are fully provisioned. This can create confusing flows where Akeyless hands you IAM credentials and when you login to AWS it says, “That access id does not exist”. This necessitates a retry flow. STS credentials generated by an assume role operation do not have such a delay.
Visibility When Akeyless creates an IAM user, you can see this user directly in the AWS console. The STS credentials from an assume role operation are not visible in AWS. This can be an advantage or disadvantage, depending on the circumstances and your perspective.
I’ve used both strategies but have a slight preference for the assume role flow. The credential lifetimes are short enough that I haven’t had to worry about revoking them early, and I’d rather not have to worry about waiting for the credentials to actually be ready after receiving them.
Your credential management strategy - e.g. telling Akeyless how to manage credentials - is what gets wrapped up in a dynamic producer. The dynamic producer points to a target (discussed above) and the combination of target and producer work together to manage your credentials: the target grants the producer access to AWS so that the producer can generate/revoke credentials.
Creating the Target and Producer
As mentioned at the start, targets and producers are created on Gateways. You can login to the configuration port (which defaults to port 8000) to configure these manually. Of course, our plan is to do as much of this as possible automatically, and this is quite simple to do through Terraform. In fact, the target and producer generation are already built into the infrastructure repository which you deployed in the last blog post. However, the target and gateway are commented out in the repository by default, since the Gateway must exist before you can create resources on it.
Open up the terraform/shared_infrastructure/akeyless.tf file and you’ll find the bottom of it commented out. I’ve also commented out some related outputs which you can enable if you would like: in the submodule and in the terraform root. Afterward, just run terraform apply again and it will create an IAM user, the target, and producer.
Note: Depending on how quickly you work through these examples, the temporary AWS admin credentials you used to deploy the infrastructure may have expired. You should be able to use a slight varation on the previous commands from last time to generate new admin credentials via assume role:
unset AWS_ACCESS_KEY_ID AWS_SECRET_ACCESS_KEY AWS_SESSION_TOKEN
aws sts assume-role --role-arn arn:aws:iam::[YOUR_ACCOUNT_ID_HERE]:role/admin --role-session-name admin > aws_credentials
export AWS_ACCESS_KEY_ID=$(jq -r '.Credentials.AccessKeyId' aws_credentials)
export AWS_SECRET_ACCESS_KEY=$(jq -r '.Credentials.SecretAccessKey' aws_credentials)
export AWS_SESSION_TOKEN=$(jq -r '.Credentials.SessionToken' aws_credentials)
rm aws_credentials
After your terraform deploy finishes, you’ll see your first dynamic producer named aws-admin in our environment’s folder (e.g. /services/products/production/aws-admin)!
Credentials Ready to Ship!
We can now issue temporary AWS access whenever we want! If you login to the main Akeyless console, you can select “Secrets & Keys” from the left menu, browse to your environment folder, find the new aws-admin dynamic producer, and hit the `Get Dynamic Secret” button:
I can even let you see a screenshot of my temporary credentials, because they are already expired! (that and you can’t see the full session token anyway!)
Final Step
Now we have a little bit of cleanup. First, we need to adjust our Terraform. We used it to create an IAM user with an access credential. That access credential went into the target and was destroyed the second we added a rotator. This is great, because it means that we don’t care if Terraform stores the old credentials in our state file (they are invalid before Terraform even finishes running). However, it’s less great, because this means that Terraform will try to create a new access key on its next run, and will muck up our rotation. Therefore, we need to remove our IAM access key and then remove the only references to it.. Just comment out the lines in those links. Akeyless will take it from there.
Gateway Deployment