aws-greengrass/aws-greengrass-nucleus

TokenExchange Service

Closed this issue · 2 comments

skulljoi commented

Describe the bug
When using node 18 and the device has support to ipv6.
the token exchange server only start on 127.0.0.1 not in both 127.0.0.1 and ::1.
So then the AWS-SDK-JAVASCRIPT try to use the address from the environment variable that comes with localhost, some times it goes to 127.0.0.1 and some times ::1, when the ::1 is is the one it is not able to get the TOKENS.

To Reproduce
Install greengrass in a device that has both protocols ipv4 and ipv6, create a simple component that need to use AWS Tokens, and you will see that it is not able to use.
Please see: aws/aws-sdk-js-v3#4048

Expected behavior
GG token exchange should work on both protocols or it could be configurable.

Actual behavior
GG Token exchange server only start on 127.0.0.1 when localhost is resolved to ::1 the AWS-SDK could not connect to the container server to grab the credentials to be use.

Environment

  • OS: rapibian / armv7l GNU/Linux
  • JDK version: openjdk 11.0.16 2022-07-19
  • Nucleus version: 2.8.1
  • Node version: v18.10.0
  • AWS SDK Javascript version: "@aws-sdk/*": "^3.192.0",

Additional context
If you bypass the address like the code bellow it works

// FIX FOR GG problem with ipv6
if (process.env.AWS_CONTAINER_CREDENTIALS_FULL_URI) {
	let localhostIpv4 = process.env.AWS_CONTAINER_CREDENTIALS_FULL_URI;
	localhostIpv4 = localhostIpv4.replace('localhost', '127.0.0.1');
	process.env.AWS_CONTAINER_CREDENTIALS_FULL_URI = localhostIpv4;
}

E.g. what is the impact of the bug?
It make the component that need to access aws resources with the TOKENS not work.

jcosentino11 commented

Hi @skulljoi, thanks for reporting the issue! We're aware of it and are currently working on a fix to have TES listen on ipv4 and ipv6. Will update this thread with progress, thanks!

jcosentino11 commented

Hi @skulljoi, after some work and discussions, we decided that we're not going to address this for now. The changes required in TES ended up not being trivial, so we don't believe it's worth introducing complexity for the following reasons. 1) This is node-specific behavior where their default DNS resolving behavior changed (since 17.x). There are workarounds for this (see below), and it looks like node is working on ipv4/ipv6 interop improvements for upcoming versions that will address this issue. 2) Greengrass doesn't officially support IPv6 at the moment.

Workarounds