Aws-cdk: AWS SSO Named Profiles Support

[vikyol]

AWS CLI v2 supports AWS SSO named profiles.

However, CDK CLI cannot resolve SSO named profiles yet.

$ cdk deploy --profile sso-named-profile

Unable to resolve AWS account to use. It must be either configured when you define your CDK or through the environment

Without this feature, users have to login to SSO user portal and fetch credentials for command line and CLI access, which needs to be repeated every time the credentials expire.

Even though CLI v2 is still in preview, it would be good to have this feature implemented for early adopters.

Use Case

• Simplify deployments to multiple-accounts for AWS SSO users.

Proposed Solution

• Read sso_start_url, sso_role_name and sso_account_id from ~/.aws/config file.
• Fetch the accessToken in ~/.aws/sso/cache/ matching sso_start_url.
• Fetch temporary credentials from STS using SSO.get-role-credentials() with accessToken, sso_account_id and sso_role_name parameters.

---

This is a :rocket: Feature Request

[shivlaks]

@excavador @Douglas-Scott can you please represent your +1 as a reaction to the feature request to capture your interest in this being implemented. It helps make it searchable and doesn't clutter up the thread.

[ReidWeb]

Given the CLI is now GA, and it seems a number of other users are facing this issue would it be possible to at least add a note to the docs indicating the lack of support at this time?

[ibex-dev]

As a temporary workaround, you can use the aws sso login feature to authenticate your CLI and export the retrieved access key ID, secret access key and session token as environment variables (json saved by default under ~/.aws/cli/cache/).
I wrote a quick bash wrapper for aws sso login that takes care of that. I invoke it once a day. If you don't feed a profile to CDK, it will look next for your env variables, so that does the trick.

[brainstorm]

@ibex-dev Would you mind sharing that bash wrapper here? :)

[nspottsie]

The mention from @victorskl above suggests using yawsso as a work around to sync the SSO credentials from ~/.aws/cli/cache to ~/.aws/credentials and it worked for me.

[beuleal]

I know its a bit old, but I'd like to contribute too.

I was facing the following error:
_Unable to resolve AWS account to use. It must be either configured when you define your CDK or through the environment_

I did a wrap for deploy into multiples account:

...
  console.log(` Setting Profile: ${account.name}`);
  let access_key = execSyncCmd(
    `aws configure get aws_access_key_id --profile ${account.name}`
  );

  let aws_secret_access_key = execSyncCmd(
    `aws configure get aws_secret_access_key --profile ${account.name}`
  );

  console.log(access_key);
  console.log(aws_secret_access_key);

  execSyncCmd(
    `aws configure set aws_access_key_id ${access_key} --profile default`
  );

  execSyncCmd(
    `aws configure set aws_secret_access_key ${aws_secret_access_key} --profile default`
  );

  execSyncCmd(`aws configure set region us-east-1 --profile default`);

  console.log(`[OK] Profile Set!`);

  execSyncCmd(`cdk deploy <stack-name> `);
...

[mateja82]

Not sure if this helps anyone, but in my organization we use AWS SSO, with over 90 AWS Accounts, with MFA, so it was impossible to manage CDK without AWS SSO support. I found a way to solve it, so till its officially relesed, you can use this, it works quite all right: MatsCloud blog - CDK with AWS SSO multi account multi profile

[gnomeria]

Actually when this issue => https://github.com/aws/aws-cdk/issues/3008 been resolved based on https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-sourcing-external.html, I think it could work. At least we have a more proper workaround. Been using https://github.com/benkehoe/aws-sso-credential-process to get the credential_process for deploying through terraform

[shortjared]

Howdy all, we solved this with exactly the following for AWS SSO... apologies for the copypaste from our internal docs but it is the quickest way to share.

Setup

The primary way you’ll likely interact with your CDK apps and AWS is through the CLI.

We’ll need a few things installed in order for a smooth process, once you do this once, you are set up for life (or until you need a new machine, whichever comes first.)

• install / update brew

Run these commands

brew install pipx
pipx ensurepath
pipx install aws-sso-credential-process
pipx install aws-export-credentials

Install AWS CLI v2… the v2 part is very important.

Add the following to you .zshrc or .bashrc or whatever.

export AWS_CONFIGURE_SSO_DEFAULT_SSO_START_URL=https://stedi-sso.awsapps.com/start
export AWS_CONFIGURE_SSO_DEFAULT_SSO_REGION=us-east-1
sso(){
  unset AWS_PROFILE
  export AWS_PROFILE=$1
  aws sts get-caller-identity &> /dev/null || aws sso login || (unset AWS_PROFILE && aws-configure-sso-profile --profile $1)
  eval $(aws-export-credentials --env-export)
}

Usage

In a new shell (after you’ve added the sso function), do a simple sso {yourteam}-dev. On the first time you do this for any new “profile” name, it will say it isn’t found and step you through an SSO process that will interact with your default browser.

The command will walk you through a series of questions that will allow the AWS profile to be configured locally.

The first thing you will see is something like “There are [some number] AWS accounts available to you. At some point, your browser will load a series of signin screens. Enter your password, etc. if you are not already authenticated. Once you are done, return to the CLI, where you will click the account that you would like to use. If there are multiple roles available to you, you will be asked to select a role.

Once you configure this for a profile, you never have to walk through the config process again. You have to log in once every X hours for a given role (depending on your org settigns), otherwise, the sso {yourteam}-dev will just drop right into those creds as well as source them into your environment.

Test that you are authenticated properly by issuing the following AWS command: aws s3 ls

Behind the scenes, this process is adding an entry to ~/.aws/config. You can always drop into that file with your favorite text editor and modify the configuration. If you later discover that you chose the wrong account or role you can remove the profile from this configuration file and repeat the above process again.

[pahud]

@shortjared Thanks for the sharing.

Instead of exposing the credentials in env var, I have another preferable approach to generate or refresh the ~/.aws/credentials instead.

https://github.com/pahud/gitpod-workspace/blob/main/utils/refresh_credentials.sh

And I use this approach to create my gitpod workspaces for aws cdk development with aws sso support.

[redbaron]

It is possible to have "native" integration with the help of aws2-wrap

Here is my ~/.aws/config :

[profile mycorp-sso]
sso_start_url = https://d-*******.awsapps.com/start
sso_region = eu-west-1
sso_account_id = 99999999999
sso_role_name = AWSAdministratorAccess
region = eu-west-2

[profile mycorp]
credential_process = aws2-wrap --process --profile mycorp-sso
region = eu-west-1

You then use mycorp profile with CDK and visual studio code.

[ryan-mars]

I started using aws-sso-util which supersedes aws-sso-credential-process as recommended by @shortjared.

It is made by @benkehoe.
https://github.com/benkehoe/aws-sso-util