Calm Cloud Security - AWS ECR Primer - Theory

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

Mar 15, 2022

0

Share this article

Links

  • 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

Transcript

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.

Containers!

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 a Container

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.

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.

Tagging

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!

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

Next Video

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, @KyMidd on twitter, and I hope this helps you level up your cloud security skills.

    img

    Related Videos

    VIDEO

    Calm Cloud Security - Containers and AWS ECR

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

    Mar 28, 2022

    0
    VIDEO

    Clean Up the AWS Kitchen Sink

    A walk through on how to evaluate cloud environments and secure them using Ident...

    Jan 27, 2022

    0
    VIDEO

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

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

    Feb 25, 2022

    0
    img

    Join the beta waitlist

    Enter your email to get notified when our product becomes available to try.

    Sign Up for the community

    Create your member profile to get involved with our content, programs, and events.