Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.
And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.
Add host.docker.internal to ContainerMetadataFetcher list of approved hosts
See original GitHub issueContainerMetadataFetcher currently allows three hosts for container metadata endpoints: 169.254.170.2, localhost, and 127.0.0.1. However, neither localhost or 127.0.0.1 represent the local docker host. Instead, the host’s localhost is reachable as host.docker.internal (docs). On Linux, the workaround is to use --network host, but on Mac and Windows this doesn’t work (the docker network is always isolated from the host).
host.docker.internal should be added to ContainerMetadataFetcher’s list of approved hosts, so that a custom metadata endpoint for testing can be run on the host rather than needing to be run in another container.
Issue Analytics
- State:
- Created 2 years ago
- Reactions:4
- Comments:6 (2 by maintainers)
Top Results From Across the Web
Top Related Medium Post
Top Related StackOverflow Question
Troubleshoot Live Code
Top Related Reddit Thread
Top Related Hackernoon Post
Top Related Tweet
Top Related Dev.to Post
Top Related Hashnode Post
I have solved this for now in my
aws-export-credentialstool by providing an IMDSv2-compatible endpoint; the IMDS endpoint is not subject to the same host checks. I think this issue still stands, though.I should note that in addition to aws-export-credentials I made a single-purpose implementation in Go: imds-credential-server
But I’d love to see this host supported in all SDKs