AWS CLI via SAML

The previous post in this series laid out how to configure the federation between a GSuite and an AWS account, with the intent on creating a single point of entry into your AWS infrastructure. This ensures that users of the infrastructure, regardless of account, authenticate into a single account, and then use role assumption based on their federation for authorization into the target account they will be working in.

While this is easy to configure and use for AWS web console users, it isn’t for developers. The concession for them was to configure an IAM user in the authentication account, and then perform role assumption. This inevitably introduces issues with credential management in a world where exposure through open repositories is rampant. I wanted to do it right for my own infrastructure, even if it meant writing my own tool. Thankfully, I didn’t have to.

In 2017, the AWS Labs team started developing awsprocesscreds to address the issue, at least for organizations that use Okta or ADFS for federation. A developer could pass in a SAML endpoint URL, their username, and the ARN of the role that they wanted to assume, with the tool returning the credential trifecta (AccessKeyId, SecretAccessKey, SessionToken) required to interact with AWS from the CLI. Unfortunately (for me), GSuite isn’t Okta or ADFS.

I took my search to GitHub, and found what I was looking for in aws-google-auth. The fine folks at cevo started working on the project in 2017, and it’s still in active development.

I cloned the repository, built from master, and installed it in a Python virtual environment using pip.

To active the Python virtual environment it’s in, I source the activate script from its directory, and the result is an identifier in the prompt of what virtual environment is active.

[~]$ source ~/.venv/aws-google-auth/bin/activate
(aws-google-auth) $ 

Once active, I added the following to my ~/.aws/config

1
2
3
4
5
6
7
8
9

[profile sso]
region = us-east-1
google_config.ask_role = False
google_config.duration = 14400
google_config.google_idp_id = redacted
google_config.role_arn = arn:aws:iam::redacted:role/saml-sts
google_config.google_sp_id = redacted
google_config.u2f_disabled = False
google_config.google_username = armen@kriation.com

1. is the name of the AWS profile that I can reference when using either aws-google-auth or awscli
2. is the region that the role_arn defined in line 6 resides
3. defines whether I will be prompted by aws-google-auth for the role
4. is the requested duration of the credentials returned by the role assumption¹
5. is the idp id referenced in GSuite
6. is the ARN of the role defined
7. is the sp id referenced in
8. defines whether U2F is enabled
9. defines the GSuite user account

The above configuration defines many of the parameters that can be passed at runtime, so you can adjust them when necessary. However, for day to day usage, I found it easier to have them set, so that calling aws-google-auth was straight forward.

After the config is set, you can run the tool:

(aws-google-auth) [~]$ aws-google-auth -p sso
Google Password: 

If all goes well, you’ll be prompted for the password associated to the address you provided on line 9 above.

If your password is correct, you’ll be prompted for your configured second factory options:

Choose MFA method from available:
2: TOTP (Google Authenticator)
3: SMS
Enter MFA choice number (3): 

Once you select your option, you’ll be prompted to enter the appropriate credential. If valid, aws-google-auth will return the following:

Assuming arn:aws:iam::redacted:role/saml-sts
Credentials Expiration: 2019-08-28 02:27:43-04:00

The ARN of the role should match what you set on line 6 in your ~/.aws/config.

Inside your ~/.aws/credentials file, you will find similar content as shown below:

[sso]
aws_access_key_id = redacted
aws_secret_access_key = redacted
aws_security_token = redacted
aws_session_expiration = 2019-08-28T06:31:17+0000
aws_session_token = redacted

Finally, you can use the credentials returned to make a call via the CLI to AWS!

[~]$ aws --profile sso sts get-caller-identity
{
    "UserId": "redacted:armen@kriation.com",
    "Account": "redacted",
    "Arn": "arn:aws:sts::redacted:assumed-role/saml-sts/armen@kriation.com"
}

In the next, and last post in this series, I’ll provide details on how I configured cross account role assumption to facilitate various tiered access across many different accounts.