Amazon Web Services

AWS Elastic Container Registry (ECR)

 is the Cloud Security Chick (well, officially the Cloud IAM Advocate) at IAM Pulse. She's part of our community team, and loves to connect with cloud operations and developers (read: that's you!). If you'd like to meet up with the community team and discuss your solutions, hacks, or how you'd like to help us elevate the practice of IAM, please reach out! 

Calm Cloud Security - AWS ECR Primer - Theory

GitHub Repo with all Commands and Terraform Code

 - You can and should run the entire demo yourself

I hope you're all doing great. Welcome back to our series on Calm Cloud Security - where we learn the theory and practice of cloud security without any gatekeeping.

As I'm recording this video, it's almost seventy degrees out, after a long, long winter! As soon as I'm finished with this video I'm going to go soak up the sun.

In our last video, we talked about what an ECR does as well as some basic theory around containers. After all that lofty theory, I want to put it into practice, and I bet you do too! In this video we'll build a container image with docker, test it, and push it to an ECR.

Let's start in the AWS console. I've already authenticated and run a terraform apply of our github terraform code, so we have an ECR. You can see the name there is "our-new-ecr", with the resource address over on the right.

Let's click into the ECR and you can see there are no images. If there were any, each one would be listed here with size, date and other info

Let's look at the image we'll be building.

First let's look at our Dockerfile. Here it is in Visual Studio Code so we get the pretty colors.

On line 1, we're grabbing the latest version of ubuntu:20.04 from the docker hub online. Docker will cache this image locally so next time we build it'll be even faster

On line 4, we're copying a script called "docker_start.sh" into the image at the "." location, which means working directory of the container's disk. Since we didn't set a working directory, docker defaults to the disk's root. We'll look at that script in a second.

On line 5, we're setting that script to be executable, which we need since we'll be running it as our next step.

And on line 9, we set an ENTRYPOINT of that same script, which means when the container launches, this script is run. As soon as the script finishes, the container will shut down and self-destruct. That's totally normal and desirable.

On line 1 and 2, we tell this script to run using bash, and "set -e" which means to exit if there's an error.

On line 5, we check to see if MY_NAME variable is set to empty. If it is, we immediately send some custom error message and exit with an exit code of "1". In almost all software, an exit code other than 0 indicates something went wrong.

If we get past that check, then on line 12 and 13 we print out a few lines of response using the MY_NAME variable. Let's not dig into that too much yet - it'll be more fun when we actually build and run it!

Let's switch to our terminal and build our docker image.

Right off, let's set some variables we'll use in our commands. First, a local docker name. Docker calls this a "repository", but this is all local, and you can use whatever name makes sense to you.

Then let's set a docker tag to use when we publish to our ECR. We'll use a really easy pattern - "latest". Latest is also assigned to images in an ECR by default if they don't have a tag.

Finally, let's actually build this container. Let's run docker build. The period means to look in the directory we're in, and the -t means a tag of the variable we set above of "hello-name". If you get an error here about failing to connect to docker make sure you have the docker service started!

Let's run "docker image ls" to look at the local docker images, and sure enough, we see our "hello-name" docker image built only a few seconds ago, awesome.

Let's test our docker image locally. The command to run a container is, intuitively, "docker run" and then the local image name.

When we do that, we see our custom error message reminding us that we forgot to set the name variable. Remember, from the entrypoint script? Checking to make sure we have all the variables we need to run successfully is a super common pattern, and custom error messages are even more best practice. Let's set the variable and build again.

We use the "-e" flag to set an environmental variable inside the launched container of MY_NAME=Kyler. Feel free to set this to your name and run it!

We get a different message, this one telling us that our container ran properly without issues, and it even politely said hello. Pretty cool.

Next up, let's push our image to the ECR!

We could hard-code the name of the ECR and the region name we built everything in, but we have direct access to terraform, and it can print these outputs, which is a really cool way to harvest info from Terraform, so let's do that instead.

We'll use the "terraform output" command to print some outputs from the configuration. Here's what that will look like.

Next let's run the same commands but trap the response as variables so we can use that info in other commands.

The way to prep our image to be pushed to a repository is to map the local image name to a remote ECR name with a tag. The "docker tag" command does the trick, like this.

And then run the "docker image ls" command to look at our images again. Now we can see what looks like a totally new image, but we didn't build a new image! If you look under "Image ID", you can see that this is the exact same image, but using a different "repository", or name.

Okay, let's push our image to the ECR! Or not! When we push, we get an auth denied message. Even though we have valid AWS credentials in the environmental variables of this terminal, our push fails. That's because the docker tool isn't able to use the AWS credentials to authenticate.

However, clever AWS engineers are prepared for this. First let's grab our region, then we can run "aws ecr get-login-password" to print a password out, and we'll use some neat bash to trap the response and pipe it right into a "docker login" command.

If you see "login succeeded" like we do, docker is now able to authenticate to the ECR, woot! Let's try that push again:

Okay, something is happening, it looks like it's pushing! Let's jump ahead to when it finishes, and we see a new error message which is very helpful - it says there is a IAM resource policy on our ECR that denies us from writing to it.

Let's switch to the AWS Console and find that ECR again, and pull up the "ECR Permissions" to find the resource policy. We do see a policy at the bottom that denied my user from putting an image into the ECR, oh no!

Let's fix it in the console. There is a graphical policy editor specific to just ECR, but I'm more comfortable editing the json directly, so let's hit "edit policy JSON" in the top right. Let's find the second stanza that is blocking my user from uploading an image to this ECR and delete it. Then let's hit save in the bottom right.

Let's switch back to our terminal and run the same command again. This time it'll succeed!

Let's spend 1 minute looking at our ECR to verify the new image is there.

When we click into the repository this time, we see the image we just pushed is now present. This ECR is internal, so any of our team can download it and run it themselves.

We can also see over on the right that AWS has already scanned this image and there are some vulnerabilities within it. Let's select details and we can see a run-down of all the vulnerabilities AWS has found.

We could take this information and go bug hunting, but that's beyond the scope of this video.

In this video we covered a lot of ground! We went over common docker and scripting patterns, build a docker image, and tested it. Then we figured out docker authentication into AWS ECR, and THEN fixed an ECR resource policy issue that blocked us from uploading an image.

We confirmed the image was present in the ECR and very briefly saw that AWS has scanned our image for vulnerabilities and we could start remediating them if we wanted.

Please find all the code we ran in the GitHub repo displayed on-screen.

I hope this has been helpful to you! You can find more of these videos at 

, and you can find me @KyMidd on Twitter if you have any feedback or questions, and I look forward to next time.

In this video we'll build a container image with docker, test it, and push it to an ECR

Calm Cloud Security - Containers and AWS ECR

Kyler's is @KyMidd on Twitter - https://twitter.com/kymidd

IAM Pulse is @CheckIamPulse on Twitter - https://twitter.com/checkiampulse

Other Primer videos - https://iampulse.com/videos

Hey all!

I hope you're doing great. I'm working with a friend to plan a tropical vacation, our first in years. It'll be the first time we've traveled further than Costco with our infant daughter, so please wish us luck!

Today we're going to be talking about the AWS ECR, or Elastic Container Registry. This is AWS's container image hosting resource - image meaning a bootable file built by docker or a similar tool. In our next video we'll actually build an ECR and docker image, then push the image to ECR with tags.

For you to understand what ECR is and how IAM can help secure it, you'll need to understand the basics of what Docker and containers are. Let's start there.

Let's do a quick walk through the history of enterprise compute and how we got to containers. 

Back in ye olden days, we had big mainframe computers! Okay, it wasn't that long ago. But these were individual operating systems on very big hardware. These are like your laptop or desktop computer - 1 OS on 1 hardware box.

Then we had virtual machines, where we had newer versions of these huge mainframe computers, and we put lots of VMs on them. Each VM is isolated, and we had a hypervisor which helped each VM share the hardware that these VMs needed to work. This saves a lot of money and provides great flexibility and operational ease. No more walking to the data center to reboot a stuck host for you!

Containers are the next evolution of compute, and they're springing up everywhere. Containers share their kernel, the central part of the OS, with the underlying hardware's kernel. This is slightly less secure, but much faster - booting a container takes only a few seconds! Containers are built to scale out, by launching more containers in a cluster, rather than scale up, like launching a larger VM or buying bigger hardware.

Lots of companies you've heard of are starting to use containers due to a host of benefits. Google, Netflix, and Uber use them extensively, but also smaller companies are finding the benefits outweigh the cons.

Let's talk about how container images are built.

Building and running containers are totally separate processes. Let's talk building them.Container images are built from a flat text file that looks like a simple shell script. Docker's build process reads this file from top to bottom, and executes the instructions to generate a binary container image that can be run by docker. Let's look at one of these files at the most common actions.


On line 1, there is a FROM command, which tells docker to use the local image on our build computer named "ubuntu" with a tag (after the colon) of "20.04", which is a version of Ubuntu. If docker can't find the image locally, it reaches out to the Docker hub, a public container registry hosted by the company that makes the docker tool. These images are very lean, and will download quickly.


Then on line 4 we have a COPY command, which takes a file from our build computer and puts it into the docker image.

Then on line 5 a RUN command which uses the native shell in the container and executes a command. In this specific example we're using chmod to make that copied file executable, but you could do anything the native shell could do. It's very common to load up tools you need for your workloads with YUM or APT.

And on line 9, the ENTRYPOINT. This is the command or service that is natively run when the container is launched. This is often the single job the host has to run. Most container running tools watch this entrypoint service, and once it stops, the container is terminated - its job is done.

Let's talk layers.

Docker's build and image registry all support the concept of layers. Each of the commands we just went over in the last section is treated as a "layer" of the container image.

Each layer is only rebuilt if that layer's command has changed, or if an upstream command has changed. For instance, if the only difference since the last build is the command on line 5, line 1 and line 4's commands aren't re-run - those layers are saved from last time and used again.

However, line 5's command has changed, so we have to recompute that layer, and that changes all the layers past it, so we have to also computer line 9, and any other line after line 5.

This isn't super important until you get into making containers build really efficiently, but you'll see layers during your build and push process and I want you to know what they are.Let's talk about tagging images.

When you build an image with docker, you have the ability to set a tag. And you should! It makes it way easier to keep track of what is what by assigning a human-readable name to your images.

Tags are comprised of a name, like "ImageName" and a version, like "v1.0.4". Both can be characters or numbers or both. You set the local tags when you build the image, and then you create a mapping between the local image name and tag to a remote name and tag, even if the remote tag doesn't exist yet.

That mapping is created entirely on your build computer, and then you "push" the image to the ECR. If "tags" and "push" sound familiar, it's because docker uses a lot of the standard concepts from git to manage code.

Push requires authentication, and we'll go over how to do that in the next video.

One other important note in container tagging on an ECR, there is the concept of tag "mutability" which is a true/false flag of whether a tag over-write is supported. Some business units want to over-write a tag like "prod" and some never want that - they'll pin their services to specific image versions and carefully control what points where.

Let's talk security!

We'd be remiss to skip over security and IAM resource policies for this resource. By default, ECRs don't have an IAM resource policy, and permit any same-account principal to connect to it from any region.

If you want to protect your ECR more strongly, or share access among several accounts, you're going to need an IAM policy for this resource. You can permit principals to only upload, only read, or anything in between.

In this video we learned all about docker and how the AWS ECR can host and protect our images.In the next video in this series we're going to get down and dirty with AWS ECR. We're going to build an ECR, build a docker image and test it locally, then tag and push that image to the ECR where other services and humans can get to it.

Please like and subscribe and come visit us at IAM pulse.com. I'm Kyler Middleton, 

 on twitter, and I hope this helps you level up your cloud security skills.

A walkthrough of AWS's container image hosting resource Elastic Container Registry (ECR) 

AWS KMS

Stephen Kuenzli of K9 Security walks us through how to evaluate cloud environments and secure them using Identity and Access Management (IAM), as well as other tools.

I'm Stephen Kuenzli, author of Effective IAM for AWS and IAM Pulse contributor.

I spent years leading AWS migrations and we always found IAM to be the hardest part. Now I’m making AWS IAM usable for Cloud teams.

Today we're going to talk about what to do when you need to clean up an AWS organization that maybe you just inherited. Or maybe it's your own organization that’s grown messy and you need to clean it up quickly.


Let's set the scene. You've just acquired another company and there are eight AWS accounts.

There are 25 known apps and at least as many data stores. Some apps are sharing IAM roles.

The access controls found in due diligence are spotty, at best.

You've been challenged with securing the critical data in those accounts within three months.

So your company can integrate features from the acquisition into your services while maintaining your security posture.

The project which created equivalent controls with custom least privilege policies for each app took a year for your other accounts. What are you going to do?




The old way? It’s too slow. It’s not going to get you there in time.

There are 25 known apps in these accounts. Each has at least one data store. Some data stores are shared.

It's not going to be possible for your organization’s two IAM experts to learn and secure two unfamiliar apps each week.

The app engineers aren't IAM experts, so they're not going to be able to write least privilege policies. At best, they can provide high-level information about what data each app needs to access.

Looks like we're headed for overloaded experts, ineffective security or both.

But there is another way. We can focus our efforts on the critical data, which is the goal of this project.

And we can use resource boundaries to protect that data.

But we still have to deploy this solution to 25 applications and at least as many data stores in time.

So we need to codify protecting data with a resource boundary in easily usable component.

So let's dig into this new solution.


Slide: Control data access with Resource Boundaries (02:27)

A resource boundary controls access to critical data and can simplify access review.

You create resource boundaries with resource policies that control access to that data resource or encryption key.

First, you control the Identity dimension: who can access the data? How?
Second, you control the Network dimension: where can authorized identities access the data from?

So you can put the access control close to the resource being protected.

Our secret weapon here is the Key Management Service, KMS.


Slide: Control Access to data with KMS (02:59)

We can control access to data with KMS. I mean, that's what encryption is all about. Encryption is not just a compliance checkmark. It’s about access control.

Encryption scrambles data, so no one can understand it unless they have the key. AWS makes encryption easy. And KMS supports resource policies so you can control who can use the key.

More than 65 data services in AWS support encrypting data with KMS. That includes all the core data services like DynamoDB and RDS.

When you encrypt data with your own customer managed key, you can control who can call encrypt, decrypt, and administration operations.

So we can identify the data for each application or data domain like Accounting, Ecommerce, or User Profiles.

Then we can encrypt that data with a dedicated key.

Now we can use KMS key policies to allow authorized applications & people the access they need and deny everyone else.

When an app or person needs to access encrypted data in a service like S3, the service will request an encryption operation on the requesting principal’s behalf.

For the request to succeed, the requesting principal must have permission to use both the data service api with the resource and the key protecting the data in that resource.

So to read an encrypted object from S3, an IAM principal must be allowed to call S3:GetObject on the object, and KMS:Decrypt on the key protecting the object.

And if you don't have privileges to encrypt or decrypt with that key, you can't read or write the data.

The details of this are explained in the book Effective IAM: Simplify AWS IAM chapter 5.


Slide: Identify Critical Data Sources (04:52)

Okay, so what are we going to do practically?

First, let's identify the critical data sources. We'll start by asking app engineers where the critical data is. They may not be able to describe a policy, but they can tell you where the data is and generally who should have access to it.

And they should be able to describe what kind of access is needed. Does their app need to read data?

Should it be able to write data to that RDS database or a DynamoDB table? Does it need to create SQS queues?

You also need to inventory the existing KMS keys and see where they're used.

Based on my experience it’s unlikely they have a key policy that prevents use by over-permissioned identities with KMS:Decrypt on all keys.

Determine what data goes together and draw a diagram. Group data resources together into their natural data domains, just like on the previous slide. This will typically align to an app or functional grouping. We’re going to create a security domain out of each of these data domains by protecting it with an encryption resource boundary.


Slide: Design your resource boundaries (05:52)

Now let’s design the encryption resource boundaries.

And pair with the application engineers to determine who needs to read and write in and out of that domain.

Often there will be multiple applications accessing certain data stores, and you'll need to give them appropriate privileges. Some app identities will need to read, some write, some both. Record this information in that same high level language.

We don't need to get into specific API actions at this point. And you don’t have time for that discussion anyway. Simply: read-write to this data store or that data store.

Now adopt a usable KMS key policy automation solution where the app engineer can understand and review the inputs.

In fact, that automation, library or tool needs to understand what you and the application engineer just described.

AppA needs to read and write to that data store.
AppB only needs to be able to read.
The CI/CD system needs to be able to administer those resources, et cetera.

Let’s see how engineers should be able to specify their intended access control.

So we can see what a usable access control automation interface should look like.

It will be close to our human readable description.

First we translate our access data table into variables that define the principals who should have each access capability.

We've lifted up the conversation from the low level details of IAM security policy to a language nonexperts can understand and review.

Now the library turns these inputs into nearly 200 lines of key policy implementing least privilege. There are statements allowing each capability for authorized principals and denying everyone else.

And this is what we need to get this job done quickly while improving security greatly.

Slide: Encrypt Everything with KMS! (07:54)

Here comes the best part. Encrypt everything!

First provision the KMS keys and policies using automation. Then Enable encryption for each data source.

Do this in Dev first, of course. We don’t want to just slap this into production.

Go switch those DynamoDB tables, switch RDS databases, S3 buckets, etc to use the key for that domain.

Now each of your critical data sources is shielded by a resource boundary.

Also recognize that these policies, and security policies in general, are really part of the application.


Now, celebrate. You've completed your mission!

You’ve also scaled security out to application engineers.

They can now take responsibility for maintaining what those inputs are. After all, they were the source of those high level access definitions. They're not necessarily equipped yet to make enhancements to the automation you adopted. But they can work with you on that.

On top of that, you've simplified Access review. Now you can both use this higher level language to discuss security controls.

And that's how you clean up an AWS kitchen sink.

I hope this has been helpful. Please feel free to contact me with questions or comments on Twitter at 

A walk through on how to evaluate cloud environments and secure them using Identity and Access Management (IAM),

Clean Up the AWS Kitchen Sink

AWS Security Token Service (STS)

Terraform

 is the Cloud IAM Advocate at IAM Pulse. She's part of our community team, and loves to connect with cloud operations and developers (read: that's you!). If you'd like to meet up with the community team and discuss your solutions, hacks, or how you'd like to help us elevate the practice of IAM, please reach out! 

IAM A Developer, What Do I Really Need to Know About IAM

 - An article from our inimitable CEO, Ivan Dwyer, on what parts of IAM are critical to know as a developer (hint: STS is in there!)

Best Practice IAM Policies, Including STS Policies

 - Our gold mine of best practice IAM and STS trust policies

I hope you’re all doing great. It is finally warming up here after a very long winter with a newborn, and I am beyond thrilled to go outside without 3 layers of coats!

During our last video we talked about what AWS STS is and why we’d do it - namely that it lets us assume a different IAM role, potentially in a different AWS account. Now that we have the foundation down, we’re going to go do it! I find that real-world experience helps me the best, so let’s get some real world experience together.

First let's look at our AWS console and the ec2 instance and the roles and policies that are in place today. I'll also publish all of the terraform used to deploy this ec2 instance and all these roles so you can build this in your own accounts and play as well!

Let's jump into the EC2 panel. Here's an ec2 instance I've created and assigned an IAM role. You can see the IAM role there in the center there. Let's click on that IAM role to view its properties.

Okay, here's the IAM role. This role exists as a separate resource from the ec2 instance. Let's scroll down a little and expand the permissions policy to see what we permit this host to do.

Okay, we can see in that json policy that we permit only using the sts:AssumeRole action on a single resource, and nothing else. This IAM role is pretty safe - it can't natively do anything, even to itself.

Let's check out the role we are allowed to attempt to assume. Let's copy the name and then go to Roles on the left and then search for that name. Let's scroll down a little and expand the permissions policy.

Oh, wow! This role has deity permissions, meaning it can do any action against any resource in the account. This is really broad! It's not a best practice - you should be limiting even your CI/CD builders to some limit, but it's a common pattern for, say, a terraform builder, which is exactly what we're going to demo here.

Let's scroll up a little and check the Trust Relationships tab for this deity assumed role. This trust relationship is STS assume related, and says who is trusted to assume the role. Since this is a deity do-anything role, we have this trust policy really limited - it can only be assumed from a single IAM role - the one we have hard assigned to the ec2 instance we created.

But that's enough theory, huh? Let's get to the terminal and do some cool stuff. This terminal is SSH'd into the ec2 instance we were just looking at.

First let's install jq. JQ stands for javascript query, and helps us parse the json that AWS will send to us for a few commands.

Then let's install terraform. First we're going to do everything using the AWS CLI, and then I'll show you how easy Terraform makes this for us. We'll wget the most recent terraform, unzip it, and drop it into our PATH.

Then we want to set a few variables we'll use in our commands. These are mostly so you can run these commands in any region world-wide and it'll work, how about that?

Next, let's look at our current identity. The AWS STS get-caller-identity command shows us that we currently are using the permissions of the "Assigned" role. That's the first role we looked at, and doesn't have any special permissions.

Let's test that theory, I have an AWS command to describe all the ec2 instances in this region. Let's run it.

And you can see it gives us an "Unauthorized" error. We don't have any rights, so it makes perfect sense that when we tried to do something, we were blocked.

But we have access to a Deity role that can do anything. Let's look at how we'd utilize it. Let's clear the screen and check out the assume command. There's a lot here, but let's check out each section. First, our command. We say use the AWS command line and the STS assume-role command. We tell it the exact ARN of the Deity role we want to assume, and give it a role session name. This session name is beyond the scope of what we're doing today, but it'd let you assume several different roles at once and do different things. Totally okay if that makes no sense.

Then let's check out the JSON-packed response. We have a credentials block with a secret access key, a token, and an access key ID. This response (rather than a permission denied error), means the STS service is granting us the rights to assume the target role, but it doesn't do it for us - we need to export the right variables into our terminal.

We could copy and paste each of the values we got into the right variables, but there is a wonderful uber-command for this. You can type this if you're very brave, but I'll include it in the github repo for easy copy and paste.

This command runs that same command we just talked about, but traps the JSON response and parses it with JQ to export all the right values in the right place. This immediately elevates our terminal commands to use the new role.

Let's check me on that - again, let's run the get-caller-identity command to see what role we're using for our commands. And we can see that we are now operating as the Deity role, the one with unfettered *:* permissions to this account.

Let's run the same command that we ran earlier that got us an error message. And we see that it worked, yay! The response isn't important to us, rather it's that we were able to do something with our new role that was blocked by our assigned role.

To revert to our assigned role, instead of the assumed Deity role, we can curl the ec2 metadata to get the creds for our implicit IAM user. Here's what that looks like - You'll see the same access key, secret access key, and token, just like before.

Let's run another uber command to do the same thing - query that node, then map the response using JQ to the local terminal variables.

And let's check our STS identity again, and we can see we're back to the assigned role.

That was a lot of commands, right? You can certainly use these commands to do assuming, but most tools make it easier. Let's run some terraform and see how easy they make it.

Here's a terraform configuration in visual studio code. Check out the AWS provider block on line 13, and specifically the assume_role command on line 15. You're now an expert at what that does - it's assuming a role as part of any resource built with this provider. Afterwards, it releases the role and the host goes back to the implicit role.

But don't listen to me, we can test this. We have a data call to find out "current identity" which is a whole bunch of stuff - region, account number, but also the IAM user doing all of this.

And we have an output that will paste the ARN of the IAM role running this command.

Let's switch over to our terminal and check our terraform command. I already have this terraform file copied to this directory, so let's run it with auto-approval.

There are no changes because there are no resources in our terraform config, but it does output the IAM user who ran the terraform - and it's our assumed deity role.

Pretty cool, huh? Terraform does all this for you.

Phew, that was a journey, wasn't it? And that's it! Now you understand IAM roles, trust policies, how to use the AWS STS command to assume and release roles, and how to use Terraform to do the same thing. And all in under 10 minutes! That's pretty cool.

Walk through assuming a different IAM role with STS assume with us

Calm Cloud Security - AWS STS Assume - AWS CLI and Terraform

AWS Secrets Manager

AWS Elastic Container Service (ECS)

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.

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.

Technical IAM Videos

Quick bite videos getting past the basics for a number of technical topics

Calm Cloud Security - Containers and AWS ECR

Calm Cloud Security - AWS ECR Primer - Theory

Clean Up the AWS Kitchen Sink

Calm Cloud Security - AWS STS Assume - AWS CLI and Terraform

Calm Cloud Security - AWS ECS IAM Primer

Calm Cloud Security - AWS STS Assume - Theory

Publish With Us!

Join the beta waitlist

Sign Up for the community