Some AWS SDK's don't support http_proxy for Instance Metadata about aws-vault

[mtibben]

Could you just do both? Write out env vars as well as use the metadata
approach?
On Tue, 13 Oct 2015 at 5:04 PM, Lachlan Donald [email protected]
wrote:

Some SDKs don't support http_proxy for Instance Metadata, which means
that they can't get credentials from aws-vault, as it exposes the server
instance via http_proxy.

The impact of this issue is that some tools just aren't able to get
credentials, like in #40
#40.

(Side note: some SDKs have very short timeouts, probably a different issue)

So whilst there is the --write-env that provides a band-aid, it's hard to
imagine how to provide a solution that would work universally. Some options
I'm considering are:

1. Change the default back to writing out environment vars and allow
   opt-in to the metadata approach
2. Provide a small daemon that would actually bind to 169.254.169.254
   and forward to the correct exec server via magic. :'(
3. ???

—
Reply to this email directly or view it on GitHub
#41.

[pda]

I'm guessing the presence of the environment variables would stop the SDK from using the instance metadata server; presumably on EC2 you can override the latter with the former…

You can't bind to 169.254.169.254 without having a network interface associated with that address/network. Dynamically reconfiguring network interfaces is another jump in complexity. It might work though, and would seem more reliable than http_proxy.

[lox]

After some thought, I think the best way forward is to do a couple of things:

• Default to writing environment vars.
• Allow opting in to --ec2-metadata, which defaults to 127.0.0.1:0 via http_proxy env.
• Allow --ec2-metadata=169.254.169.254, which will work if you've run the contrib/lo-ec2-metadata.sh script that will be written.
• Add an aws command for invoking the aws cli with the correct params.

[mtibben]

Perhaps you could introduce the idea of profiles - a set of environment var config to make a certain command or sdk work. The default profile should attempt to work in most use cases, but you could potentially have boto or old-aws or ruby-sdk profiles to give those environments what they're expecting

[lox]

It's tempting @mtibben, but I'd rather something that simply works for everything.

[lox]

Fixed in master.