Welcome to AWS ECS IAM Primer!
Hope your 2022 is off to a great start. I’m at home with my 3 month old as it snows outside today, just a wonderful day. I thought today I’d cover the basics of how IAM works with an AWS ECS cluster, since IAM exists at a few different layers there.
My name is Kyler Middleton, and I’m a Cloud IAM Advocate here at IAM Pulse, which means I am doing my best to educate practitioners and elevate IAM knowledge everywhere I can. So if you’re listening to this now, thanks for helping me with my goal!
Okay, with no further ado, let’s do this!
Let’s define some terms before we get too far. If you know all this, don’t worry - it’ll be super fast. ECS is Elastic Container Service, and is AWS’s pre-packaged tool to run containers. You can set any number of containers you’d like, and even schedule them, and it’l launch and maintain your container pool.
IAM is any security and access policy you use to govern who can do what, where. ECS interestingly uses IAM at several layers here, and we’ll go deep into that. In fact, let’s do that now.
ECS IAM Layers
Just like the ogres of Shrek, ECS IAM has layers. Let’s talk about the several layers you need to worry about here. Both of these configurations are part of the “task” definition in ECS, which is the same object that contains the container launch properties, size of the container, stuff like that.
The first is called an Execution Role. This IAM role is used in order to gather all the information needed to launch the container. Common items at this layer at the actual container image stored in an ECR, or a container registry, any secrets stored in the secrets manager service, and also the key used to encrypt those same secrets.
Since IAM is in effect both at the request and response layer, we need to permit this access both at the execution IAM policy as well as each resource that we want IAM to reach out to. There are some intra-account easy defaults that’ll help you, but if you’re going cross account for any of this info you’re going to get really familiar with IAM really quickly here.
The second layer of IAM is the “task role,” which is the IAM role handed to the launched container. This one should contain all the appropriate permissions for the service you’re launching to do what it needs to do.
The third layer, that you’ll only run into sometimes, is if you need your task IAM role to assume another role. Make sure that the role assigned to your task is able to use the STS assume service which lets IAM roles assume things, and permit it to assume the target IAM role. You’ll also need to configure the target IAM role to permit assuming from the ECS service.
I have a deep dive of doing cross-account CI/CD builders using ECS in this article, and we have a real world use case for all of this stuff at IAMPulse.com. Come check it out, and please subscribe there as well - we’ll be publishing lots of interesting stuff in the coming months!