You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When I have no existing session established with AWS (e.g. starting work first thing in the morning), if I run a command like aws s3 ls --profile <profile_name> on a profile that uses granted credential_process, it seems granted "swallows" the browser code prompt that typically shows when running something like assume <profile_name> first.
When running assume first, output is (shows the browser code for comparison):
[i] If the browser does not open automatically, please open this link: https://start_url.awsapps.com/start/#/device?user_code=ABCD-EFGH
[i] Awaiting AWS authentication in the browser
[i] You will be prompted to authenticate with AWS in the browser, then you will be prompted to 'Allow'
[i] Code: ABCD-EFGH
If I have not executed assume first and attempt to run an AWS CLI command like aws s3 ls --profile named_profile, then I get:
❯ aws s3 ls --profile named_profile
The command waits until the browser code and prompt is authorized, however, it doesn't show the code for comparison.
I'm just wondering if this is a shortcoming on the granted side, or if it's behavior that comes from the way AWS CLI handles things with credential_process? Is there anything that can be done to ensure the browser code is displayed in the terminal in this case?
Expected output would be more like:
❯ aws s3 ls --profile named_profile
[i] If the browser does not open automatically, please open this link: https://start_url.awsapps.com/start/#/device?user_code=ABCD-EFGH
[i] Awaiting AWS authentication in the browser
[i] You will be prompted to authenticate with AWS in the browser, then you will be prompted to 'Allow'
[i] Code: ABCD-EFGH
The text was updated successfully, but these errors were encountered:
It seems like this might be more of an AWS CLI thing and less about granted. Using a line like this can help with still displaying the browser code: credential_process = sh -c "granted credential-process --auto-login --profile named_profile 2>/dev/tty"
Thanks for the issue @dariushall-mr. Sadly this is indeed a limitation of the AWS CLI - the CLI doesn't show stdout/stderr, and will only print it after a command has failed.
Thanks @chrnorm, is the workaround I posted something that can make it in to the credential process docs for granted - would that make sense? Just from a security perspective, it seems like having that code swallowed is disadvantageous to users (though maybe a minor issue).
Yes, definitely! The code being swallowed is indeed a security concern, so this looks like a great approach to improve that. The docs repo is here if you'd like to take a crack at contributing it :D
When I have no existing session established with AWS (e.g. starting work first thing in the morning), if I run a command like
aws s3 ls --profile <profile_name>
on a profile that uses granted credential_process, it seems granted "swallows" the browser code prompt that typically shows when running something likeassume <profile_name>
first.I have my ~/.aws/config file set up as follows:
When running assume first, output is (shows the browser code for comparison):
If I have not executed assume first and attempt to run an AWS CLI command like
aws s3 ls --profile named_profile
, then I get:The command waits until the browser code and prompt is authorized, however, it doesn't show the code for comparison.
I'm just wondering if this is a shortcoming on the granted side, or if it's behavior that comes from the way AWS CLI handles things with credential_process? Is there anything that can be done to ensure the browser code is displayed in the terminal in this case?
Expected output would be more like:
The text was updated successfully, but these errors were encountered: