Update Packer to Support STSCreds for AWS Builder

[chriswgerber]

There is an additional credential provider missing from the AWS Access Config because it is not available in the credentials chain: Assume Role Provider

This page explains a bit about role switching and gathering the key, secret, and token which can be used to authenticate using a static provider. https://docs.aws.amazon.com/sdk-for-go/api/service/sts/STS.html#AssumeRole-instance_method

The two required values for the AssumeRoleInput (RoleArn, RoleSessionName) are usually declared in the aws config file (located $HOME/.aws/config by default) with with a profile name and a matching source profile (See http://docs.aws.amazon.com/cli/latest/topic/config-vars.html).

Ideally, in a Packer template file, there would be a variable for the AWS EC2 builder called "profile_name" that we could specify an AWS profile name and have the builder pull the values for the configuration and credentials from that profile. The priority on this credential provider would be below the SharedCredentials provider. A profile name could be declared in the builder, but would be overridden by explicitly declared access keys, secret keys, and tokens. The profile name could be used to pull access key, secret key, and session tokens from named profiles in the credentials file.

All of this would eliminate one of the many ways that credentials are often hardcoded into files, as well as make it easier to rotate keys. With profile and role switching, one single set of access and secret keys can be used to manage multiple accounts, so a single set of keys can be rotated often for many accounts.

I would like to contribute myself, but I'm not a Go developer so I'm trying to contribute to getting this feature added in any way I can.

[cbednarski]

Thanks for opening an issue. Does this work if you specify the AWS_PROFILE environment variable? Packer is pretty hands-off with respect to credentials. aws-sdk-go does most of the work here.

If that is not working or I missed something and that doesn't address your use-case, please let me know.

[chriswgerber]

It won't work. There are a few other open issues right now that would be fixed with the update, as well.

The stscreds provider is not called in the chain provider, so it wouldn't pick up the necessary values from both the credential file and the config file. The config file ($HOME/.aws/config) stores the information for how a profile would go about getting access, secret, and session keys. If it needs to switch to a source profile and pull those values from the credentials file, it will do that. The credential file (used by the SharedCredentialsProvider) stores those values in named profiles.

Example file:

$ ~/.aws/credentials

[default]
aws_access_key_id = (access_key)
aws_secret_access_key = (secret_key)

[root_profile_name]
aws_access_key_id = (another_access_key)
aws_secret_access_key = (another_secret_key)

The Config file would point those named credentials via source_profile, and the STS provider would use the source credentials to make the API call to retrieve session values from the secondary account.

Example Config File

$ ~/.aws/config

[profile profile_name]
region = us-west-2
role_arn = arn:aws:iam::account_id:role/role_name

[profile another_profile_name]
region = us-west-2
role_arn = arn:aws:iam::another_account_id:role/role_name
source_profile = root_profile_name

The AWS SDK won't pull in those values and match them automatically. It's something that has to be explicitly created and passed to the credential provider. I have done a similar implementation that I've done in Ruby that I could provide if you'd like. Edit: aws/aws-sdk-go#384 AWS has said that they won't implement directly, as well, meaning it would be a requirement of the application to implement it. Even if the configuration file isn't used, I think it would be acceptable if we could at least declare those values directly in the builder configuration and have it generate the credentials via the STS service.

Using the AWS CLI, simply passing the profile name is enough to authenticate and run commands because the application does the work to look up config by first by passed variable, then config file, then environmental variable. (source).

It would be nice if we could do the same thing here: Pass a profile name and have the application use that profile to switch and get the credentials. Otherwise default to ENV variables or instance metadata.

[cbednarski]

I see. Thanks for providing additional details for this and linking to the upstream to clarify! I'm open to adding support for this but I won't be able to jump on it right away.

My feeling is that this is not very complex to implement but testing it will be rather complicated. I did notice the sdk docs say that the STS credentials should not go in the credentials chain.

[chriswgerber]

Thanks for your response.

I can provide testing on the branch, if that would help. I'm just not a Go programmer. However, if your timeline puts this several months out, I may need to dig in deeper with Go and help, as well. We'd like to get the above workflow rolled out, but we need either an update to Packer or an intermediate script to set up ENV variables. Having the functionality included in Packer would make it much more maintainable.

[chriswgerber]

I told a stab at it and put together this: https://github.com/ThatGerber/packer/commit/883acb18fac2c732e7fdf05822959bb45977ed00

You can see the basic flow: If a profile name is provided, the other credentials aren't needed and can be scraped from the CLI config files. First you have to authenticate as a source AWS profile, then switch over to the role of another profile.

[mafonso]

Any updates on this? Does not seem to be supported in 0.11.0 yet.

It would be nice to get rid of the aws sts assume-role on a wrapper script.

[rickard-von-essen]

@mafonso See #4124

[mwhooker]

fixed in #4996

[ghost]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.

If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.