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:
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
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.