Panic when using EcsContainer and AWS_CONTAINER_CREDENTIALS_FULL_URI

[rnett]

Describe the bug

According to the AWS docs AWS_CONTAINER_CREDENTIALS_FULL_URI should be used when AWS_CONTAINER_CREDENTIALS_RELATIVE_URI is not set. However the SDK does not seem to do this. Instead, it panics.

Expected Behavior

When EcsContainer is used as the credential source but AWS_CONTAINER_CREDENTIALS_RELATIVE_URI is not set, the SDK falls back to using AWS_CONTAINER_CREDENTIALS_FULL_URI.

Current Behavior

It panics when EcsContainer is used as the credential source but AWS_CONTAINER_CREDENTIALS_RELATIVE_URI is not set:

panic: SharedConfigErr: EcsContainer was specified as the credential_source, but 'AWS_CONTAINER_CREDENTIALS_RELATIVE_URI' was not set

goroutine 1 [running]:
github.com/aws/aws-sdk-go/aws/session.Must(...)
        github.com/aws/aws-sdk-go@v1.44.35/aws/session/session.go:381
github.com/weaveworks/eksctl/pkg/eks.(*ClusterProvider).newSession(0xc0005cc1e0, 0xc0001b59a8)
        github.com/weaveworks/eksctl/pkg/eks/api.go:514 +0x6e5
github.com/weaveworks/eksctl/pkg/eks.New({0x549dac8, 0xc00012c008}, 0xc0001b59a8, 0xc00027afc0)
        github.com/weaveworks/eksctl/pkg/eks/api.go:150 +0xda
github.com/weaveworks/eksctl/pkg/ctl/cmdutils.(*Cmd).NewCtl(0xc0001b5970)

Reproduction Steps

Use eksctl version 0.112.0 on Cloud Shell with the following config in ~/.aws/config:

[profile test]
    role_arn = // some role to assume
    credential_source = EcsContainer

then run

export AWS_PROFILE=test
 eksctl create cluster --name test

I don't expect the actual command to matter.

Possible Solution

Respect the documented behavior.

Additional Information/Context

No response

AWS Go SDK V2 Module Versions Used

Whatever eksctl version 0.112.0 uses.

Compiler and Version used

Whatever eksctl version 0.112.0 uses.

Operating System and version

Linux, 4.14.287-215.504.amzn2.x86_64 (AWS Cloud Shell)

[RanVaknin]

Hi @rnett,

Sorry for the long response time. It looks like the behavior you described does match the credential provider code here.

There is no fallback case.

However I do see that in v2 we do have that fallback functionality, so I encourage you to use v2.

Thanks,
Ran~