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.
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.
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 = email@example.com
- is the name of the AWS profile that I can reference when using either aws-google-auth or awscli
- is the region that the role_arn defined in line 6 resides
- defines whether I will be prompted by aws-google-auth for the role
- is the requested duration of the credentials returned by the role assumption1
- is the idp id referenced in GSuite
- is the ARN of the role defined
- is the sp id referenced in
- defines whether U2F is enabled
- 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:
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:
Once you select your option, you’ll be prompted to enter the appropriate credential. If valid, aws-google-auth will return the following:
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:
Finally, you can use the credentials returned to make a call via the CLI to AWS!
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.
Tweet to @kriation