Receiving an error="NoCredentialProviders:

[ryron01]

I am trying this out for the first time and I was stopped in my tracks and don't know how to troubleshoot further. I use an AWS profile configuration to assume a role in an account. Is this supported? Am I overlooking something obvious?

guzzi:~ $ cloud-nuke --version
cloud-nuke version v0.1.13

guzzi:~ $ env | grep -i aws
AWS_PROFILE=secret-profile-name

guzzi:~ $ aws sts get-caller-identity
{
"UserId": "AROAI3SSNQ5VVVVMPHPQA:botocore-session-1579734394",
"Account": "xxxxxxxxxxxxx",
"Arn": "arn:aws:sts::xxxxxxxxxxxx:assumed-role/TeamRole/botocore-session-1579734394"
}

guzzi:~ $ cloud-nuke aws --region us-west-2 --dry-run
INFO[2020-01-22T15:14:22-08:00] Retrieving active AWS resources in [us-west-2]
INFO[2020-01-22T15:14:22-08:00] Checking region [1/1]: us-west-2
ERRO[2020-01-22T15:14:42-08:00] *awserr.baseError NoCredentialProviders: no valid providers in chain. Deprecated.
For verbose messaging see aws.Config.CredentialsChainVerboseErrors
/go/src/github.com/gruntwork-io/cloud-nuke/aws/asg.go:18 (0x16d48ea)
/go/src/github.com/gruntwork-io/cloud-nuke/aws/aws.go:204 (0x16d8468)
/go/src/github.com/gruntwork-io/cloud-nuke/commands/cli.go:149 (0x16eac46)
/go/src/github.com/gruntwork-io/cloud-nuke/vendor/github.com/gruntwork-io/gruntwork-cli/errors/errors.go:93 (0x15ef2cb)
/go/src/github.com/gruntwork-io/cloud-nuke/vendor/github.com/urfave/cli/app.go:490 (0x15ddfa2)
/go/src/github.com/gruntwork-io/cloud-nuke/vendor/github.com/urfave/cli/command.go:210 (0x15df315)
/go/src/github.com/gruntwork-io/cloud-nuke/vendor/github.com/urfave/cli/app.go:255 (0x15dc108)
/go/src/github.com/gruntwork-io/cloud-nuke/vendor/github.com/gruntwork-io/gruntwork-cli/entrypoint/entrypoint.go:21 (0x16ecc37)
/go/src/github.com/gruntwork-io/cloud-nuke/main.go:13 (0x16ecec7)
/usr/local/go/src/runtime/proc.go:195 (0x102b626)
/usr/local/go/src/runtime/asm_amd64.s:2337 (0x10577e1)
error="NoCredentialProviders: no valid providers in chain. Deprecated.\n\tFor verbose messaging see aws.Config.CredentialsChainVerboseErrors"

[brikis98]

This does look like a bug. Not sure what the cause is. Perhaps some AWS Go SDK issue? If anyone has a chance to dig in and take a look, I believe this is where we configure the session for auth: https://github.com/gruntwork-io/cloud-nuke/blob/master/aws/aws.go#L40

[JamesSmallGE]

I am an encountering what I believe to be a similar issue. My use case is to use issue a command on account A -and role A to account B role B. And with the credentials from account B role B, run the cloud-nuke. However, it is querying for resources belonging to account A. -- I suspect that, as you mentioned, there is an issue in the AWS Go SDK. Similar to in the past, where the 'boto' library could not make use of roles for containers. If you wanted to use roles with containers, you had to use boto3 library. I am speculating that there is an issue with the AWS Go SDK such that it is not providing the 'account' ID for the assumed role, and instead (in my case, providing the original account ID), and in the submitter's case, providing 'no id' (no credentials). --- Unfortunately I do not have a solution to this either.

[JamesSmallGE]

bash-5.0$ aws sts get-caller-identity
{
"UserId": "RANDOMQ6WMAOU4UGLFW5XM:NukeWrapper",
"Account": "ACCOUNTB",
"Arn": "arn:aws:sts::ACCOUNTB:assumed-role/AshesToAshes/NukeWrapper"
}
bash-5.0$ ./cloud-nuke aws --older-than 24h --dry-run
INFO[2020-02-04T18:50:55Z] Retrieving active AWS resources in [eu-north-1, ap-south-1, eu-west-3, eu-west-2, eu-west-1, ap-northeast-2, ap-northeast-1, sa-east-1, ca-central-1, ap-southeast-1, ap-southeast-2, eu-central-1, us-east-1, us-east-2, us-west-1, us-west-2]
INFO[2020-02-04T18:50:55Z] Checking region [1/16]: eu-north-1
ERRO[2020-02-04T18:50:58Z] awserr.requestError AccessDeniedException: User: arn:aws:sts::ACCOUNTA:assumed-role/ROLEA/i-instanceidgoeshere is not authorized to perform: eks:ListClusters on resource: arn:aws:eks:eu-north-1:ACCOUNTA:cluster/
status code: 403, request id: 87bfaf3c-698b-4533-9bed-932ba07484b3
/go/src/github.com/gruntwork-io/cloud-nuke/aws/eks.go:41 (0xadf5b1)
/go/src/github.com/gruntwork-io/cloud-nuke/aws/aws.go:350 (0xad2ee4)
/go/src/github.com/gruntwork-io/cloud-nuke/commands/cli.go:149 (0xae6cd6)
/go/src/github.com/gruntwork-io/cloud-nuke/vendor/github.com/gruntwork-io/gruntwork-cli/errors/errors.go:93 (0x9eb35b)
/go/src/github.com/gruntwork-io/cloud-nuke/vendor/github.com/urfave/cli/app.go:490 (0x9da032)
/go/src/github.com/gruntwork-io/cloud-nuke/vendor/github.com/urfave/cli/command.go:210 (0x9db3a5)
/go/src/github.com/gruntwork-io/cloud-nuke/vendor/github.com/urfave/cli/app.go:255 (0x9d8198)
/go/src/github.com/gruntwork-io/cloud-nuke/vendor/github.com/gruntwork-io/gruntwork-cli/entrypoint/entrypoint.go:21 (0xae8cc7)
/go/src/github.com/gruntwork-io/cloud-nuke/main.go:13 (0xae8f57)
/usr/local/go/src/runtime/proc.go:195 (0x42bca6)
/usr/local/go/src/runtime/asm_amd64.s:2337 (0x458971)
error="AccessDeniedException: User: arn:aws:sts::ACCOUNTA:assumed-role/ROLEA/i-instanceidgoeshere is not authorized to perform: eks:ListClusters on resource: arn:aws:eks:eu-north-1:ACCOUNTA:cluster/*\n\tstatus code: 403, request id: 87bfaf3c-698b-4533-9bed-932ba07484b3"
bash-5.0$

[JamesSmallGE]

This is a bug in the SDK https://docs.aws.amazon.com/sdk-for-go/v1/developer-guide/configuring-sdk.html. It specifically identifies the order in which credentials will be used. The behavior is different from the documentation. You can get around the issue by explicitly setting AWS_ACCESS_ID, AWS_SECRET_ACCESS_KEY, (and) AWS_SESSION_TOKEN, at which point, the GO SDK will then properly use the credentials you expect, and cloud-nuke (in my case) will execute commands looking for resources in the correct account

[breml]

I have cloud-nuke working with profiles and assume role. In my case, it was necessary to export AWS_SDK_LOAD_CONFIG=true as well (see: https://docs.aws.amazon.com/sdk-for-go/v1/developer-guide/configuring-sdk.html). With this additional env var, cloud-nuke picked up my config from ~/.aws including the role_arn and source_profile bits.

export AWS_SDK_LOAD_CONFIG=true
export AWS_PROFILE=foobar
cloud-nuke aws --dry-run

[sam-fakhreddine]

I have cloud-nuke working with profiles and assume role. In my case, it was necessary to export AWS_SDK_LOAD_CONFIG=true as well (see: https://docs.aws.amazon.com/sdk-for-go/v1/developer-guide/configuring-sdk.html). With this additional env var, cloud-nuke picked up my config from ~/.aws including the role_arn and source_profile bits.

export AWS_SDK_LOAD_CONFIG=true
export AWS_PROFILE=foobar
cloud-nuke aws --dry-run

This fixed my issue 100%

[marinalimeira]

Given this issue has already been solved, I am closing this issue :)