Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Provide an environment variable to disable IMDSv2 path #2980

Closed
joelthompson opened this issue Nov 27, 2019 · 4 comments
Closed

Provide an environment variable to disable IMDSv2 path #2980

joelthompson opened this issue Nov 27, 2019 · 4 comments
Labels
feature-request A feature should be added or improved.

Comments

@joelthompson
Copy link

Is this related to a problem?

The IMDS code has a 5-second timeout in fetching data from the IMDS, which includes trying to fetch the IMDSv2 session token. This can cause slowness when running inside of a Docker container, especially when multiple calls to the IMDS are involved in serial each of which uses a different EC2Metadata client. This seems to have been reported in #2972

I'm a HashiCorp Vault community member who often helps with Vault integrations with AWS. I submitted a PR to update the version of the aws-sdk-go to a recent version to take advantage of IMDSv2, but the potential hit to the user experience for users running inside of Docker containers seems poor -- it'll take some time for full adoption of IMDSv2 to the entire AWS ecosystem such that the default hop limit can be set to two to allow for workloads running in Docker containers (e.g., I don't believe that, as of today, autoscaling groups or Fargate tasks support non-default Metadata options). Until then, while I think this is a great capability to add to Vault, it should really provide end users with a fallback option/"escape hatch" to disable the use of IMDSv2 until the penetration of IMDS support has achieved critical mass to where it's no longer needed.

Feature description

Provide an environment variable, e.g., AWS_EC2_DISABLE_IMDSV2, which will cause the SDK to always fall back to IMDSv1.

Describe alternatives you've considered

  1. Accept the 5-second timeout which can happen serially for clients and provide a poor user experience.
  2. Don't adopt IMDSv2 and consequently don't realize the security benefits it has to offer.

Additional context

n/a

@mkantzer
Copy link

The ruby SDK has a similar issue (aws/aws-sdk-ruby#2177) , with more information from a maintainer that has discussed options with the EC2 teams: aws/aws-sdk-ruby#2177 (comment)

essentially, EC2 doesn't want an ENV to skip IMDSv2.

It seems the associated PR after their discussion (aws/aws-sdk-ruby#2182) sets IMDSv2 retries to 1, and timeouts to 1 by default.

@ruudk
Copy link

ruudk commented Mar 28, 2020

I've spend hours debugging why kube-ingress-aws-controller was hanging for minutes on startup after upgrading aws-sdk-go. The solution is obviously to increase the hop limit, but in some setups this is not immediately possible.

Please support a way to disable the IMDSv2 via a env var or config setting in Go.

@skmcgrail
Copy link
Member

Closing this issue, as there is no intention to add a feature for disabling the IMDSv2 path within the SDKs.

@github-actions
Copy link

⚠️COMMENT VISIBILITY WARNING⚠️

Comments on closed issues are hard for our team to see.
If you need more assistance, please either tag a team member or open a new issue that references this one.
If you wish to keep having a conversation with other community members under this issue feel free to do so.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature-request A feature should be added or improved.
Projects
None yet
Development

No branches or pull requests

4 participants