AWS EC2 Provisioner does not support temporary credentials with session token.

[nathanpeck]

Many corporate or high security environments vend temporary AWS credentials to access an AWS account. These credentials have three factors: AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, and AWS_SESSION_TOKEN. Without all three the authentication will fail.

Currently the AWS EC2 provisioner supports specifying the access key, and secret key, but does not support specifying a session token. As a result inletsctl will attempt to make AWS API calls with only the first two factors, and auth will be rejected.

Expected Behaviour

I should be able to optionally specify a session token when calling inletsctl create, or inletctl should make use of the environment variables: AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, and AWS_SESSION_TOKEN as this is the recommended way to set temporary credentials to a specific shell session.

Current Behaviour

inletsctl does not support session tokens.

Context

By default AWS credentials last forever, until revoked. Many orgs instead use temporary AWS credentials which have a session token and expire. Without support for this form of auth it is hard to use inletsctl in orgs that require the use of temporary credentials.

More docs on temporary AWS credentials here: https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_use-resources.html

Your Environment

Version: 0.8.6 Git Commit: f0b3d64de575204b425bad99bd9b8a5d891cbb68

[alexellis]

Thanks for raising this. You could also set up your VM as required and download the inlets server manually, or using CloudFormation/TF/Pullumi.

Inletsctl uses cloud init, so a similar approach is what I'd expect to work with other tooling.

I would be interested in any possible solution that you may see? That was part of the original template. How does the AWS SDK enable the third leg of authentication?

@Waterdrips may also have ideas or @rgee0

[rgee0]

This should be relatively straightforward to implement. It’s a case of capturing a new flag value and passing it through to the provisioner, which currently passes “” in the token field.

You’d probably want to split the two suggested approaches. Offer through a flag initially and then consider environment variables later.

[rgee0]

https://github.com/inlets/cloud-provision/pull/8 is the first part

[rgee0]

105 provides for the use of temporary credentials.

@nathanpeck if you're interested I'd appreciate an extra set of eyes on the testing.

[rgee0]

Doco here:https://github.com/inlets/docs/pull/18

[alexellis]

Thanks @rgee0 that was excellent timing 👍

Nathan, you can still set up your tunnel servers however you like, but inletsctl 0.8.8 now supports the request above:

https://github.com/inlets/inletsctl/releases/tag/0.8.8