AWS API and CLI Access for Google Apps SAML

“worms eye view of buildings” by Alex wong on Unsplash

We’ve recently decided to remove all AWS IAM users with long lived access keys for our developers. This gives us greater peace of mind that all AWS access keys, that have very wide permissions, will be short lived.

There’s two parts to removing AWS IAM users, AWS console access and AWS API or CLI access. Replacing IAM user Console access with Single Sign-On (SSO) is a fairly simple and well travelled process, setup a SAML 2.0 federated provider such as Google Apps and you’re pretty much done. API or command line access is not as straight forward, especially if you’ve setup Google Apps SAML and want to use the same role mappings.

There are a few Open-Source CLI apps out there that solve this, what we didn’t like was having developers provide their username and passwords for the apps to perform the HTML scraping dance and grab an SAML assertion before it was sent to AWS so the CLI could use it for STS role assumption. This felt brittle and hacky, not things you want when trying to be more secure…

So we developed a service that could bridge the gap between the OAuth2 flow which is well suited to what we want to do here and the SAML role mapping we’ve already setup in Google Apps.

The AWS credentials broker service is deployed in an AWS account and given both Google OAuth2 client credentials and a Google Admin Service Account User that has access to read user information (i.e. the SAML role mappings).

The flow is as follows:

• A CLI starts a HTTP listener on a random port and a browser window to the AWS credentials broker with a localhost callback URI to its HTTP listener.
• The AWS credentials broker uses its Google OAuth2 client credentials to authenticate the user and get an OpenID Connect (OIDC) token for the user.
• Once a user has been authenticated with Google the AWS credentials broker uses its Admin Service Account user to list the SAML roles associated with the now authenticated user.
• If the user has more than one role, the AWS credentials broker allows the user to select which account role they want to assume using a React based UI.
• When a user has picked a role to assume, the Google OIDC token for the user is given to AWS STS to assume the role using STS’s web identity federation.
• The user is then redirected to the localhost callback URI supplied at the beginning with the temporary credentials. The CLI can then save them in the users’ AWS credentials file ~/.aws/credentials for use with the AWS CLI or SDK as they would with standard access keys.

Multiple role mappings choice is presented to the user

Assuming you already have the Google SAML provider & roles setup in AWS. The only update you need in AWS is to add a trust relationship for our Google OAuth Client ID for any roles you want users to be able to assume. For example:

{
  "Version": "2012-10-17",
  "Statement": [
    ...
    {
      "Effect": "Allow",
      "Principal": {
        "Federated": "accounts.google.com"
      },
      "Action": "sts:AssumeRoleWithWebIdentity",
      "Condition": {
        "StringEquals": {
          "accounts.google.com:aud": "<google client id>"
        }
      }
    }
    ...
  ]
}

The most difficult part of the setup we found was getting a Google Service Account for the credentials broker to read the SAML role mappings in the Google Admin User Directory.

After successfully assuming a role

The aws-credentials-broker is available here: https://github.com/flowcommerce/aws-credentials-broker