Hangs on startup after trying to use credential_process

[garthk]

AWS Toolkit for Visual Studio Code doesn't launch properly, and doesn't say why.

To Reproduce

• Set up a profile using credentials_process and source_profile, where the source_profile also has mfa_serial
• Open VS Code
• Observe blue clock icon over AWS button in activity bar
• Click AWS button in activity bar
• Observe “AWS: EXPLORER” open
• Observe blue dash moving from the left to the right at the top of the screen
• Observe no other visible activity
• Use View: Toggle Output command (⇧⌘U)
• Click Output tab
• Choose AWS Toolkit from selector on right
• Observe no content in output window
• Choose AWS Toolkit Logs from selector on right
• Observe “Error logs for this session are permanently stored in …aws_toolkit_20191214T105409.log”
• Observe no other content in output window
• Observe no content in the named log file
• Wait long enough to type all that
• Observe nothing changed
• Look through the directory containing the log file
• Observe mention of ~/.vscode/extensions/amazonwebservices.aws-toolkit-vscode-1.4.0 and the error below
• Look through that directory
• Hope AWS isn't writing to their source directory
• Launch VS Code again
• Get an error this time (see below)

Reckon it might have tangled its storage after this:

2019-12-14 10:40:19 [ERROR]: Could not generate 'configure' code lens for handler 'mymodule.handler' Error: Unable to find a sam template associated with handler 'mymodule.handler' in /Users/garthk/src/myproject/myhandler.js.
	at /Users/garthk/.vscode/extensions/amazonwebservices.aws-toolkit-vscode-1.4.0/out/src/shared/codelens/codeLensUtils.js:126:15
	at Generator.next (<anonymous>)
	at fulfilled (/Users/garthk/.vscode/extensions/amazonwebservices.aws-toolkit-vscode-1.4.0/out/src/shared/codelens/codeLensUtils.js:8:58)
2019-12-14 10:40:19 [ERROR]: Could not generate 'configure' code lens for handler 'mymodule.handler' Error: Unable to find a sam template associated with handler 'mymodule.handler' in /Users/garthk/src/myproject/myhandler.js.
	at /Users/garthk/.vscode/extensions/amazonwebservices.aws-toolkit-vscode-1.4.0/out/src/shared/codelens/codeLensUtils.js:126:15
	at Generator.next (<anonymous>)
	at fulfilled (/Users/garthk/.vscode/extensions/amazonwebservices.aws-toolkit-vscode-1.4.0/out/src/shared/codelens/codeLensUtils.js:8:58)
2019-12-14 10:43:45 [INFO]: > Downloading latest toolkits endpoint data
2019-12-14 10:43:58 [ERROR]: ForbiddenException, AccessDeniedException: User: arn:aws:sts::999999999999:assumed-role/RoleName/1576280623495873000 is not authorized to perform: schemas:ListRegistries on resource: arn:aws:schemas:us-west-2:999999999999:*
	at Object.extractError (/Users/garthk/.vscode/extensions/amazonwebservices.aws-toolkit-vscode-1.4.0/node_modules/aws-sdk/lib/protocol/json.js:51:27)
	at Request.extractError (/Users/garthk/.vscode/extensions/amazonwebservices.aws-toolkit-vscode-1.4.0/node_modules/aws-sdk/lib/protocol/rest_json.js:55:8)
	at Request.callListeners (/Users/garthk/.vscode/extensions/amazonwebservices.aws-toolkit-vscode-1.4.0/node_modules/aws-sdk/lib/sequential_executor.js:106:20)
	at Request.emit (/Users/garthk/.vscode/extensions/amazonwebservices.aws-toolkit-vscode-1.4.0/node_modules/aws-sdk/lib/sequential_executor.js:78:10)
	at Request.emit (/Users/garthk/.vscode/extensions/amazonwebservices.aws-toolkit-vscode-1.4.0/node_modules/aws-sdk/lib/request.js:683:14)
	at Request.transition (/Users/garthk/.vscode/extensions/amazonwebservices.aws-toolkit-vscode-1.4.0/node_modules/aws-sdk/lib/request.js:22:10)
	at AcceptorStateMachine.runTo (/Users/garthk/.vscode/extensions/amazonwebservices.aws-toolkit-vscode-1.4.0/node_modules/aws-sdk/lib/state_machine.js:14:12)
	at /Users/garthk/.vscode/extensions/amazonwebservices.aws-toolkit-vscode-1.4.0/node_modules/aws-sdk/lib/state_machine.js:26:10
	at Request.<anonymous> (/Users/garthk/.vscode/extensions/amazonwebservices.aws-toolkit-vscode-1.4.0/node_modules/aws-sdk/lib/request.js:38:9)
	at Request.<anonymous> (/Users/garthk/.vscode/extensions/amazonwebservices.aws-toolkit-vscode-1.4.0/node_modules/aws-sdk/lib/request.js:685:12)
	at Request.callListeners (/Users/garthk/.vscode/extensions/amazonwebservices.aws-toolkit-vscode-1.4.0/node_modules/aws-sdk/lib/sequential_executor.js:116:18)
	at Request.emit (/Users/garthk/.vscode/extensions/amazonwebservices.aws-toolkit-vscode-1.4.0/node_modules/aws-sdk/lib/sequential_executor.js:78:10)
	at Request.emit (/Users/garthk/.vscode/extensions/amazonwebservices.aws-toolkit-vscode-1.4.0/node_modules/aws-sdk/lib/request.js:683:14)
	at Request.transition (/Users/garthk/.vscode/extensions/amazonwebservices.aws-toolkit-vscode-1.4.0/node_modules/aws-sdk/lib/request.js:22:10)
	at AcceptorStateMachine.runTo (/Users/garthk/.vscode/extensions/amazonwebservices.aws-toolkit-vscode-1.4.0/node_modules/aws-sdk/lib/state_machine.js:14:12)
	at /Users/garthk/.vscode/extensions/amazonwebservices.aws-toolkit-vscode-1.4.0/node_modules/aws-sdk/lib/state_machine.js:26:10
	at Request.<anonymous> (/Users/garthk/.vscode/extensions/amazonwebservices.aws-toolkit-vscode-1.4.0/node_modules/aws-sdk/lib/request.js:38:9)
	at Request.<anonymous> (/Users/garthk/.vscode/extensions/amazonwebservices.aws-toolkit-vscode-1.4.0/node_modules/aws-sdk/lib/request.js:685:12)
	at Request.callListeners (/Users/garthk/.vscode/extensions/amazonwebservices.aws-toolkit-vscode-1.4.0/node_modules/aws-sdk/lib/sequential_executor.js:116:18)
	at callNextListener (/Users/garthk/.vscode/extensions/amazonwebservices.aws-toolkit-vscode-1.4.0/node_modules/aws-sdk/lib/sequential_executor.js:96:12)
	at IncomingMessage.onEnd (/Users/garthk/.vscode/extensions/amazonwebservices.aws-toolkit-vscode-1.4.0/node_modules/aws-sdk/lib/event_listeners.js:307:13)
	at IncomingMessage.emit (events.js:205:15)
	at IncomingMessage.EventEmitter.emit (domain.js:471:20)
	at endReadableNT (_stream_readable.js:1154:12)
	at processTicksAndRejections (internal/process/task_queues.js:84:9)

… so if you're in the mood to split a bug with multiple causes, you'll want one to catch the AccessDeniedException and help the user fix it rather than tangling your state.

I'm not sure why that resulted in the explorer hanging, but eventually something timed out or otherwise resolved and I got some proper errors:

There was an issue trying to use credentials profile myprofile: User: arn:aws:iam:: …:user/… is not authorized to perform: sts:AssumeRole on resource: arn:aws:iam:: 999999999999:role/RoleName

… revealing that you didn't use the credential_process. Searching with that as a keyword…

• @mpiroc raised Write design document for credential_process support. #617 for a design document, which kinda implies it doesn't work
• Add credential_process support #317 ends with a statement it works in 1.1.0
• Load AWS credentials from credential_process #749 looks like a PR making it work
• I'm using 1.4.0 in which it isn't working despite that

Now that the AWS Explorer menu is working again, it offers “Connect to AWS…”, which is right. But, it's still not using the credential_process, so I'm still getting errors.

I can't reproduce the hang.

Despite "aws.logLevel": "verbose" in my settings.json, there are no log messages either in VS Code's Output or in Code/logs/aws_toolkit since the one above.

Expected behavior

I expect AWS Explorer to use my profile, even if I'm using credential_process, so it can fit in with my existing AWS practices.

I expect AWS Explorer to provide extra log detail when I set "aws.logLevel": "verbose" so I can help its developers solve the problem.

Desktop (please complete the following information):

• OS: macOS 10.15.1
• Visual Studio Code Version: 1.41.0
• AWS Toolkit for Visual Studio Code Version: 1.4.0

[awschristou]

Thank you for the detailed information. Looks like there are some things to investigate.

In the meantime, would you be able to try connecting with credentials that use only credentials_process and not source_profile (and vice versa)? I'd appreciate knowing how these behave on your system (if possible).

[awschristou]

Hey, I thought I'd address some portions of your comments...

Observe mention of ~/.vscode/extensions/amazonwebservices.aws-toolkit-vscode-1.4.0 and the error below

These appear to be call stack entries, which corresponds to the extension's code being executed. The toolkit shouldn't be making changes in here at run-time.

2019-12-14 10:43:58 [ERROR]: ForbiddenException, AccessDeniedException: User: arn:aws:sts::999999999999:assumed-role/RoleName/1576280623495873000 is not authorized to perform: schemas:ListRegistries on resource: arn:aws:schemas:us-west-2:999999999999:*

These type of occurrences should surface as error nodes in the AWS Explorer tree (see image below). These nodes have a context menu, which will show you the error message as well. If this is not the experience you got, I'm interested in hearing what happens in your case. (You may have hit an error before the tree was able to populate)

Despite "aws.logLevel": "verbose" in my settings.json, there are no log messages either in VS Code's Output or in Code/logs/aws_toolkit since the one above.

When the log level setting is changed, it currently does not take effect until VS Code is restarted. I've opened #860 to track this. (Having said that, we could stand to use some more logging)

There was an issue trying to use credentials profile myprofile: User: arn:aws:iam:: …:user/… is not authorized to perform: sts:AssumeRole on resource: arn:aws:iam:: 999999999999:role/RoleName

This sounds like it is related to the combination of credential_process and source_profile, which still needs to be investigated.

[zerkz]

I noticed that the current version of AWS toolkit (Version: 1.4.0) doesn't respect/use credential_process in the source_profile's definition. It does respect a credential_process when its defined in the explicit profile.

[default]
mfa_serial=arn:aws:iam::adsadasdadqwewqacasfa:mfa/AnAWSUser
region = us-east-1
credential_process=aws-vault exec default --json

[profile dev-sandbox-staff]
region=us-east-1
source_profile=default
role_arn=arn:aws:iam::ahgasfsedfaewfweaf:role/Staff

Even though the default profile has the ability to AssumeRole on the staff profile, the toolkit throws a "missing credentials error message".

Apologies if this is unrelated.

[bryceitoc9]

Hi @zerkz

Looks like we forgot to update this; we released a new credential handling system in January; are you still running into this issue?

Thanks!