Support AWS CLI v2 AWS Single Sign-On

[e-moshaya]

https://aws.amazon.com/about-aws/whats-new/2019/11/use-the-aws-cli-v2-preview-with-aws-single-sign-on-to-increase-developer-productivity/

https://aws.amazon.com/blogs/developer/aws-cli-v2-now-supports-aws-single-sign-on/

I am using aws 2 with SSO integration to authenticate via command line. However, terraform is not recognising the configuration with the error below:

Error: No valid credential sources found for AWS Provider.
	Please see https://terraform.io/docs/providers/aws/index.html for more information on
	providing credentials for the AWS Provider

  on ../../modules/arangodb-terraform-module/providers.tf line 1, in provider "aws":
   1: provider "aws" {

[gdavison]

Thanks for submitting this issue, @e-moshaya. I'd like to clarify what you're seeing.

When you're trying to use the AWS SSO credentials with Terraform, what are the commands you execute on the command line?

Does calling aws2 sts get-caller-identity give you the credentials you expect?

[e-moshaya]

Hi @gdavison lookslike aws2 sso doesn't use ~/.aws/credentials file at all as all I have in my ls ~/.aws/ directory is:

cli	config	sso

The ~/.aws/config has:

[profile default]
sso_start_url = https://sso.awsapps.com/start
sso_region = eu-west-2
sso_account_id = 359814823534
sso_role_name = AdministratorAccess
region = eu-west-2
output = json

The output for aws2 sts get-caller-identity are as expected:

{
    "UserId": "AROAR2UFOKOFEBO4KCB56:[email protected]",
    "Account": "359814823534",
    "Arn": "arn:aws:sts::xxxxxxxxxxx:assumed-role/AWSReservedSSO_AdministratorAccess_22134e45a32c8395/[email protected]"
}

However, the output for aws v1 is not working:
aws sts get-caller-identity

Unable to locate credentials. You can configure credentials by running "aws configure".

[gdavison]

As a workaround, if either of the ~/.aws/cli or ~/.aws/sso files are structured like the old ~/.aws/credentials file, for now you could add the shared_credentials_file parameter to your Terraform configuration.

I do see that https://docs.aws.amazon.com/cli/latest/userguide/install-cliv2.html says that the v2 CLI is not ready for production use, but this is definitely something that needs to be implemented.

[e-moshaya]

@gdavison both sso and cli are folders with cache files in them.. There are no shared credentials files involved.

[ken5scal]

looking forward to it

[borrell]

FWIW, in the meantime this wrapper exists that will generate temporary credentials using aws2 then export them to the current session

aws2-wrap --profile SSOProfileName --exec "terraform plan"

https://github.com/linaro-its/aws2-wrap

(found here aws/aws-cli#4668).

It works great when you only need a single set of credentials for a deployment, but I haven't figured out a way to generate a second set as needed (e.g. separate profiles for providers and backends).

[borrell]

AWS CLI v2 is now generally available.

https://aws.amazon.com/blogs/developer/aws-cli-v2-is-now-generally-available/

[eistrati]

Is there any timeline to this feature? Would be cool to see when this feature would be supported natively by terraform aws provider. We have been using https://github.com/ddimitrioglo/aws-saml implementation for various automations, but embedding aws cli v2 would be an important step for us going forward!

[bflad]

In my cursory looking, its my understanding that the AWS Go SDK will need to first implement support for the sso_* configurations in the shared configuration file (e.g. in https://github.com/aws/aws-sdk-go/blob/master/aws/session/shared_config.go) or at least the SSO token cache (based off https://github.com/aws/aws-cli/tree/v2/awscli/customizations/sso). Depending on that implementation, the Terraform AWS Provider will either implicitly support SSO token access by nature of updating the AWS Go SDK or we can enable any necessary configurations to do so. I do not see any current upstream GitHub issues relating to this, so it may be worth starting there: https://github.com/aws/aws-sdk-go/issues

That being said, it is very likely that the Terraform AWS Provider cannot (or at least should not) implement the full SSO login workflow via opening a browser on expired SSO tokens unless there is support in the AWS Go SDK for this as well.

[b-dean]

The AWS SDK GO v2 is in a different repo: https://github.com/aws/aws-sdk-go-v2

It doesn't seem to have the same sessions and config stuff as the other sdk. Their example looks pretty different.

[ChristophShyper]

Looks like CLI now supports SSO: https://docs.aws.amazon.com/cli/latest/reference/sso/index.html#cli-aws-sso
Updated today.

[claytonsilva]

Hi everyone, i read @borrell solution but, the solution from aws2-wrap is not safe for multiple profiles in same project.
to solve this problem, i forked to
https://github.com/claytonsilva/aws-sso-cred-restore

and now i fill ~/.aws/credentials file with my sso profiles (more than 1 in a single command)

I solve my problema until terraform solve this problem like azure provider experience.

[flyinprogrammer]

I took at stab at writing a credential_process to solve this problem, which means you won't need to call scripts randomly, most applications are already smart enough to properly re-call the process when the credentials expire: https://github.com/flyinprogrammer/aws-sso-fetcher

it also does some caching so that sequential calls use a file until the credential expires.
It's pretty alpha software, but it seems to work ¯_(ツ)_/¯ Issues and feedback welcome.

[mknapik]

We had to use terraform with AWS account which supported SSO login only. Since AWS access key and secret expire, we've created a bunch of scripts to workaround the issue. I thought I'd share them here you might find it useful.
Check out fragment from our Taskfile.yml (yaml based task runner, Makefile substitute): https://gist.github.com/mknapik/7220a2dda4a66b2710784b7a658bd491
Running task aws:login would login with SSO if necessary and migrate credentials to the format understood by terraform.

[Geethree]

Nice @mknapik Though I recommend you take a look at @flyinprogrammer 's work above yours... basically it is similar to the ecr-cred-helper for docker login. Quite.. a lovely workaround!

[valorl]

While the workaround is nice, it would be great to have this supported natively. Which project is this awaiting right now and are there any issues we can go vote on ?

[dogzzdogzz]

Hi guys, don't know if this can help in some way, in the sense is not an actual solution for the issue, BUT we have developed a project just to help with this kind of compatibility issues, it's here on github: https://github.com/Noovolari/leapp and helps by enabling AWS SSO and third party tools to communicate, it connects to your AWS SSO managing all your accounts and roles but saves temporary credentials in .aws/credentials so it could address this issue for example.

Storing creds in clear text is a bad idea

But better than my terraform not functional.
aws-vault still encounters credential issue when you want to run terraform plan in account A with profile A but its tfstate file is stored in the s3 bucket of account B which need to be accessed with profile B.

[FernandoMiguel]

aws-vault still encounters credential issue when you want to run terraform plan in account A with profile A but its tfstate file is stored in the s3 bucket of account B which need to be accessed with profile B.

You should login to an account that allows you to assume roles to both accounts.
That's the correct way.
Seems you are trying to fix the wrong thing.

[willhughes-au]

That's the correct way.

That's not always possible, and not everyone agrees with this point of view.

For me, we are not going to ever have that ability - I need to use multiple accounts concurrently. None of the terraform configuration is in the other accounts, and you can't assume-role between those accounts.

[FernandoMiguel]

That's the correct way.

That's not always possible, and not everyone agrees with this point of view.

For me, we are not going to ever have that ability - I need to use multiple accounts concurrently. None of the terraform configuration is in the other accounts, and you can't assume-role between those accounts.

You have SSO right?
At least that's the topic of this thread.
Why wouldn't the use of the SSO account to assume roles be the correct way?

[willhughes-au]

I think you're talking about the other form of SSO where you'd use AssumeRole.

This is about AWS SSO, which does not involve AssumeRole to authenticate.

You use a specific profile to access an account and a specific permissionset

like this:

[profile sso]  
sso_start_url = https://example.awsapps.com/start  
sso_region = us-east-1  
sso_account_id = xxx  
sso_role_name = AWSReadOnlyAccess  
region = ap-southeast-2  

For me to access resources in account A, I need profile A
For me to access resources in account B, I need profile B.

While technically I suppose I could then do an AssumeRole from Account A to Account B, this would require cross-account trusts/roles that permit this.
This would then require that we duplicate the work we put into setting up PermissionSets and managing users/groups/etc in AWS SSO.

[ericvilla]

Hi @e-moshaya, as you know, as far as know AWS CLI v2 support for AWS SSO generated temporary credentials under ~/.aws/cli/cache folder which in many cases end up with "credentials not found" issue. I want to share - with people who want to solve this issue - the link to the GitHub repo of the Open Source project my team is working on. With new support to AWS SSO, it allows you to retreive - prior configuration of the Portal URL - a list of IAM Role that the AWS SSO user - you are logging in with - has access to. From this flat list you can generate temporary credentials with a click. Well, there are other details that you can find here

[prnvkbr]

I am not sure if this has been mentioned before, but this workaround worked for me:

1. On your AWS SSO landing page, click on the "Command line or programmatic access" link.
2. Copy Option 2 (contains profile, aws_access_key_id, aws_secret_access_key, aws_session_token)
3. On your local machine, create a or append to an existing ~/.aws/credentials and paste the text selected from step 2.
4. Use terraform

[willhughes-au]

@prnvkbr Those credentials, like all SSO credentials, are short lived. While you can do that, others have already provided examples of tools that will also do this.

[onitake]

While the suggestions of workarounds and tools to make Terraform work with AWS SSO are appreciated, can we focus on the issue at hand, namely that the Terraform provider doesn't support it natively? Maybe by simply updating to a newer aws-go-sdk version? As suggested in #10851 (comment) , aws-go-sdk can handle SSO credentials.

Is someone working on this already?

[anarsen]

@onitake If it's not on the roadmap then I don't think so, no.

[jonasneves]

Another workaround in case it helps anyone:

# Create access keys in aws cli cache
data "external" "caller_id" {
  program = ["aws", "sts", "get-caller-identity", "--output", "json"]
}

# Fetch credentials from aws cli cache. Requires jq pkg
data "external" "aws_creds" {
  program    = ["jq", ".Credentials", "${pathexpand("~")}/${tolist(fileset(pathexpand("~"), ".aws/cli/cache/*.json"))[0]}"]
  depends_on = [data.external.caller_id]
}

provider "aws" {
  access_key = data.external.aws_creds.result["AccessKeyId"]
  secret_key = data.external.aws_creds.result["SecretAccessKey"]
  token      = data.external.aws_creds.result["SessionToken"]
  region     = local.vars.aws_region
}

[bflad]

AWS Go SDK version 1.37.0 now includes native SSO cached credential support: aws/aws-sdk-go#3755

Will work on coordinating this dependency update.

[bflad]

Support for AWS Single-Sign On (SSO) cached credentials has been merged and will release with version 3.26.0 of the Terraform AWS Provider later today. When the release is available, an automated release comment will be sent to this issue.

There are no future plans to support the AWS SSO login flow (e.g. web browser interaction) in Terraform CLI or the Terraform AWS Provider due to the complexity of operations across products. Feature requests for such functionality will be closed.

Please note that neither Terraform CLI nor the Terraform AWS Provider will initiate or perform the AWS SSO login flow. It is expected that you have already performed the SSO login flow using AWS CLI with the aws sso login command, or by some other mechanism before executing Terraform. More precisely, this credential handling must find a valid non-expired access token for the AWS SSO user portal URL in ~/.aws/sso/cache. If a cached token is not found, is expired, or the file is malformed an error will be returned.

You can use configure AWS SSO credentials from the AWS shared configuration file by specifying the required keys in the profile:

sso_account_id
sso_region
sso_role_name
sso_start_url

For example, the following defines a profile "devsso" and specifies the AWS SSO parameters that defines the target account, role, sign-on portal, and the region where the user portal is located. Note: all SSO arguments must be provided, or an error will be returned.

[profile devsso]
sso_start_url = https:my-sso-portal.awsapps.com/start
sso_role_name = SSOReadOnlyRole
sso_region = us-east-1
sso_account_id = 123456789012

Additional Resources

• Configuring the AWS CLI to use AWS Single Sign-On
• AWS Single Sign-On User Guide

Equivalent update for the Terraform S3 Backend can be found here: hashicorp/terraform#27620 (targeting next Terraform CLI 0.15 release and can be backported if another Terraform CLI 0.14 release is expected)

[ghost]

This has been released in version 3.26.0 of the Terraform AWS provider. Please see the Terraform documentation on provider versioning or reach out if you need any assistance upgrading.

For further feature requests or bug reports with this functionality, please create a new GitHub issue following the template for triage. Thanks!

[onitake]

There are no future plans to support the AWS SSO login flow (e.g. web browser interaction) in Terraform CLI or the Terraform AWS Provider due to the complexity of operations across products. Feature requests for such functionality will be closed.

I think that's a perfectly reasonable decision. While it does require the user to install another tool besides Terraform to perform authentication, at least supporting credentials managed by other (standard) tools is probably sufficient for most users.

Thank you very much for the work!

[rajkshah14]

Now as SSO is enabled, can this documentation be updated?
https://registry.terraform.io/providers/hashicorp/aws/latest/docs#shared-credentials-file

@bflad

[ghost]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.

If you feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. Thanks!