Discover Your IAM Role With: sts get-caller-identity

When I’m working with AWS managed services like Beanstalk, ECS, Lambda, CodePipeline, CodeBuild, or whatever, I often have difficulty remembering which roles and policies these managed services are operating under. The aws sts get-caller-identity command provides a quick solution to this problem. As the documentation says, it…

Returns details about the IAM user or role whose credentials are used to call the operation.

aws.sts get-caller-identity documentation

You typically find the AWS CLI installed on the services I mentioned so you can just run the command (no permissions are required to run it) and it will very clearly display the role (or user) you’re currently operating with.

I recently figured this out while debugging some permissions issues with a CodePipeline pipeline. I had a relatively simple pipeline that checked source out of CodeCommit, built it with CodeBuild and then deployed it to S3 from CodePipeline. When I added a Terraform command to the CodeBuild script I started seeing Access Denied errors.

I was working on the assumption that the CodeBuild operations were being performed with the role I assigned to the CodeBuild job but then I started thinking maybe I had that wrong and it was actually the CodePipeline roles. My confidence was sinking.

When I continued to have no luck adding the necessary permission, I decided I needed to verify that I was making changes to the correct role. A little digging around got me to the the get-caller-identity API so I added it to my buildspec.yml as follows:

install:
  runtime-versions:
    nodejs: 10
  commands:
    - aws sts get-caller-identity

A quick check of the CloudWatch logs for the build confirmed that I was in fact making changes to the correct role (it was using the role assigned to CodeBuild).

Feeling a little more confident, I dug back into the policies attached to the role and discovered that s3:ListObjects is not a valid action in an IAM Policy statement. It’s a little unfortunate because the failure occurred on a ListObjects API call but the correct statement action ended up being s3:ListBucket.

Although my call to get-caller-identity only confirmed what I had suspected to be true, it made me more confident to keep digging into the policy to get it right. Too often the desire is to just throw a * in there, see that it works and move on. A little more context can help keep your policies only as permissive as they need to be.