[v2] credentials supplied by aws sso login do not conform to AWS standards

[dayer4b]

AWS documents that credentials generated by aws configure are stored in the standard path ~/.aws/credentials:

The AWS CLI stores the credentials that you specify with aws configure in a local file named credentials, in a folder named .aws in your home directory.

https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-files.html

This path is not utilized by credentials stored by aws configure sso or aws sso login.

Other tools (like Terraform and Boto3) that rely on this standard do not function because they do not see the credentials stored in the ~/.aws/cli/cache/ JSON files.

Shared credential file (~/.aws/credentials)

https://boto3.amazonaws.com/v1/documentation/api/latest/guide/configuration.html

[dayer4b]

For my own purposes, I am working around this issue by extracting the data from the JSON object and dumping it into the ~/.aws/credentials file as such:

#!/bin/bash

JSON_BASEPATH="${HOME}/.aws/cli/cache"
AWS_CREDENTIALS_PATH="${HOME}/.aws/credentials"

if [ -f ${AWS_CREDENTIALS_PATH} ]; then
        echo "backing up existing credentials"
	cp -rf ${AWS_CREDENTIALS_PATH} "${AWS_CREDENTIALS_PATH}-"$(date +"%s")
fi

# find the latest CLI JSON file

json_file=$(ls -tr "${JSON_BASEPATH}" | tail -n1)

# use jq to dump stuff in the right place

aws_access_key_id=$(cat ${JSON_BASEPATH}/${json_file} | jq -r '.Credentials.AccessKeyId')
aws_secret_access_key=$(cat ${JSON_BASEPATH}/${json_file} | jq -r '.Credentials.SecretAccessKey')
aws_session_token=$(cat ${JSON_BASEPATH}/${json_file} | jq -r '.Credentials.SessionToken')


echo "[default]" > ${AWS_CREDENTIALS_PATH}

echo "aws_access_key_id = ${aws_access_key_id}" >> ${AWS_CREDENTIALS_PATH}
echo "aws_secret_access_key = ${aws_secret_access_key}" >> ${AWS_CREDENTIALS_PATH}
echo "aws_session_token = ${aws_session_token}" >> ${AWS_CREDENTIALS_PATH}

I hope this helps others until a fix is ready!

[KaibaLopez]

Hi @dayer4b ,
To make sure I understand the problem here,
you've ran the configure sso command and logged in and are able to use the various services with the generated temporary credentials right?

aws sso login --profile my-sso-profile
aws s3 ls --profile my-sso-profile

this kind of call works for you, but when running through another sdk, it is not recognizing the credentials. Am I understanding correctly?

[heikkis]

@KaibaLopez that is the current best solutions I think we agree. Those STS creds are valid only for an hour so you have to generate those quite often.

This is not a good solutions. SSO does not always create new cache json files so you actually need to clear cache folder beforehand to be sure that the newest file is created by AWS cli.

[KaibaLopez]

I think I'm missing something here, but this is not really a problem on the CLI, unless it is not working for you for cli actions either it'd be a problem with how you're getting credentials on the other sdks. You're right that you shouldn't need to move them manually, but each sdk has it's own way of retrieving credentials when it comes to sso logins, make sure that you're doing it correctly, it might need extra configuration.

Also, not sure if this was part of the problem but sso is meant to be temporary so not sure I can offer you a solution there.
Again let me know if I missed something here or you don't agree with my response, I do feel like I'm not getting the full picture...

[heikkis]

I think you are correct in away. I think that it would be nice that cli would provide supported way for SSO STS creds like you can get those from the portal. Now this "hook" is way too complex and error brone.

Support could be very similar to STS lookup with MFA code.

[rossmckelvie]

I think the problem OP is describing is really a feature request for the aws terraform provider. I found a feature request over on the provider repo related to supporting SSO credentials: hashicorp/terraform-provider-aws#10851

[lorengordon]

Doing this on a utility-by-utility or sdk-by-sdk basis will make for an absolutely horrid developer and user experience.

The SDKs all support the AWS Shared Config file in some way. The SSO auth/cred process should also integrate through the AWS Shared Config so all SDKs and all utilities are able to leverage it the same way.

[KaibaLopez]

@lorengordon
Yes,and we are trying to unify the sdk's behaviors, but I think you misunderstood what I meant there, it's not as bad as that.
It's more on the default credentials provider chain, I'm not familiar with how terraform does theirs, but they should have a way to read the credentials from the same place as the cli, it just may not be the default, that's what I meant by extra steps, not that you'd need to modify the code but that you'd need a different method call.
All this being said, I'd recommend checking those sdk's documentation or opening an issue on their repos regarding this, it still sounds to me like there is no problem with the CLI's implementation.

[lorengordon]

@KaibaLopez Ok, gotcha. I use terraform a lot and have also helped review/expand the credential handling to better work with the features of the AWS Shared Config. It will indeed leverage the SDK credential chain properly. The only known real issue currently is that IF you are using the AWS_PROFILE env and that profile uses certain features from the AWS Shared Config file, then you must export AWS_SDK_LOAD_CONFIG=1. That's kind of a thing in the aws-sdk-go for enabling resolution for the AWS Shared Config.

Far as I can tell, I don't think there is truly a terraform issue here.