Packer: amazon: Document profile option

Created on 12 Apr 2017  ·  5Comments  ·  Source: hashicorp/packer

I own multiple accounts that aren't able to share AMIs for various reasons. The ability to define AWS Profile to use from my ~/.aws/credentials file for each builder would be very nice.

Example:

...
"builders": [
    {
      "type": "amazon-ebs",
      "aws_profile": "profile-1",
      ...
    },
    {
      "type": "amazon-ebs",
      "aws_profile": "profile-2",
      ...
    }

The effect would be the ability to spin up multiple AMIs in multiple accounts without having to change the environment variable AWS_PROFILE between runs. Would also alleviate the need to change VPC and Subnet IDs between accounts.

bug buildeamazon docs

Most helpful comment

Yes for that use case the profile option is needed and after some thinking I would like to keep it and document it.

we don't want to control aws authentication through packer, since aws does a much better job of that. Adding a profile option does just that.

(https://github.com/hashicorp/packer/pull/4996#issuecomment-308278968)

Profile is not really handling auth with packer it's more an enabler for use to leverage the aws sdk by telling it which config to load. For sure you could use AWS_PROFILE env var, but as many points out limits it to one which is not mapping well against the possibility to run multiple (aws) builders.

So my (final) vote ✋ is on keep profile and add it to the docs.

All 5 comments

It is actually supported with the undocumented option profile.

We are debating if we should remove it or document it. Please add your opinion to https://github.com/hashicorp/packer/pull/4613#issuecomment-284533875

(Moved this here since it's relevant for this issue.)

As I think we discussed, we don't want to control aws authentication through packer, since aws does a much better job of that. Adding a profile option does just that.
I'm fine leaving it in for backwards compatibility, but I don't want to document it because I don't want to support it

See https://github.com/hashicorp/packer/pull/4996#issuecomment-308278968

I think we can either:
1) Document this and mark it as deprecated.
2) Leave it as an undocumented feature and keep this open until we decide to keep it or remove it.

@rickard-von-essen what about the use case mentioned here, of having multiple builders that each need a separate profile?

It doesn't seem possible to support that by having the user set AWS_PROFILE, so the only way to do that would be to support the profile option. I'm fine with this.

If you don't think that's a use case that should be supported, then I think that's a separate discussion

Yes for that use case the profile option is needed and after some thinking I would like to keep it and document it.

we don't want to control aws authentication through packer, since aws does a much better job of that. Adding a profile option does just that.

(https://github.com/hashicorp/packer/pull/4996#issuecomment-308278968)

Profile is not really handling auth with packer it's more an enabler for use to leverage the aws sdk by telling it which config to load. For sure you could use AWS_PROFILE env var, but as many points out limits it to one which is not mapping well against the possibility to run multiple (aws) builders.

So my (final) vote ✋ is on keep profile and add it to the docs.

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.

Was this page helpful?
0 / 5 - 0 ratings