🦄 Making great presentations more accessible.
This project aims to enhances multilingual accessibility and discoverability while maintaining the integrity of original content. Detailed transcriptions and keyframes preserve the nuances and technical insights that make each session compelling.
Overview
📖 AWS re:Invent 2025 - Enhancing container security with Amazon ECR (CNS208)
In this video, Liz Duke, Principal Specialist SA for Containers at AWS, presents CNS 208 on enhancing container security with Amazon Elastic Container Registry. She explains the challenges of managing hundreds or thousands of container images and introduces the container supply chain concept. The session covers how Amazon ECR provides fully-managed Docker registry capabilities with built-in security features including IAM integration, encryption at rest, and vulnerability scanning options. Duke highlights the enhanced scanning integration with Amazon Inspector that detects both OS and application vulnerabilities, continuous scanning capabilities, and the newly launched fully managed container image signing with AWS Signer. She also discusses runtime monitoring using Amazon GuardDuty for ECS and EKS clusters to detect suspicious behavior like botnet connections or data exfiltration.
; This article is entirely auto-generated while preserving the original presentation content as much as possible. Please note that there may be typos or inaccuracies.
Main Part
Container Security Challenges and the Container Supply Chain Approach
Good evening. Thank you for attending this final session of the day. This is CNS 208: Enhancing Container Security with Amazon Elastic Container Registry. My name is Liz Duke, and I'm a Principal Specialist SA for Containers at AWS. I work with container customers across the UK, Ireland, and the wider EMEA region.
Every day, thousands of organizations successfully deploy containers, powering everything from your favorite streaming services to critical healthcare applications. Behind these seamless experiences are teams just like yours. Today, I'm excited to talk to you about how AWS services can work together to make container security feel less like a checkpoint and more like an accelerator, building security into every stage of your container journey.
Let's dive into the sorts of challenges for security that you face when running container workloads. While you may start off small with only a few container images, typically that doesn't last and you end up managing hundreds or even thousands of container images. Each of these images needs to be checked for security, not only when they're built but throughout the lifecycle of that container image. The more images you have, the more finding security problems is like finding a needle in a haystack. We expect container images to be switched out often, and with this pace and speed of change comes the ability for mistakes to affect your security profile.
Container images are built up from multiple layers, typically starting with a base OS image layer and then adding your application, bringing in any libraries, any further dependencies, and maybe even some open source components. All of these layers need checking for any container security issues. So how do we do this? We follow and build a container supply chain.
A container supply chain is built up of the components used to build and store container images and deliver them with a container orchestrator. We start from your code repository, which is where your application code lives. Then we build a container image up from multiple layers, and each of these layers can be pulled from almost anywhere depending on your security constraints. Once we've built the image, we need to store it somewhere, and that's where your container registry comes into play. From then on, we use a container orchestrator to deploy your images. This last step isn't typically part of a container supply chain, but I've included it because I think it's really important, and that's to monitor your images when they're up and running to see if they're behaving as you expect them to.
Let's look at how we can add security to each of these stages of your container supply chain. Ideally for security, you want to automate all the stages of your container supply chain, from code submission to your repository all the way through to deploying your images on your running workloads with your orchestrator. For this, we can use a service called AWS CodePipeline. AWS CodePipeline works with Identity and Access Management, so it can integrate with other AWS services using that. When you automate this using a pipeline, you end up taking humans out of the loop, which is a great improvement for your security.
You start off with a developer submitting code into your code repository. Typically these days, this is some form of Git repository. When that code is submitted and pushed to the repository, CodePipeline will be notified and then it will take this new submission using a temporary access token. Once we've got the code from your repository, we want to put this code together with the other layers to build your container image, and you could use AWS CodeBuild for that. At this stage, once you've built your image, you might want to sign that image to make sure that it's not changed from when you build it to when you deploy it, and you could use a service like AWS Signer to do that.
Let me introduce you to the secret weapon for your container security in your build supply chain, and that is Amazon Elastic Container Registry. It not only stores your container images, but it can also check them for vulnerabilities.
We're going to deploy our container images using your orchestrator of choice. Within AWS, we have two main container orchestrators: Amazon ECS, Elastic Container Service, and Amazon EKS, Elastic Kubernetes Service. Once you've confirmed everything's good to go from the build point of view, you want to get those images into your workload. Let's take a closer look at Amazon ECR and the security benefits that it brings.
Amazon ECR Security Features: From Vulnerability Scanning to Image Signing
Amazon ECR is a fully-managed Docker registry. There's a private ECR registry supplied to each AWS account. With ECR, you can store and distribute your Docker images, open container images, or any other OCI-compatible artifacts. When you transfer an image to ECR, you do so over HTTPS, bringing security into the process, and your container images are automatically encrypted at rest. Amazon ECR is highly available with redundant architecture and serves billions of image pulls every single day.
Remember the needle in the haystack problem I mentioned? With Amazon ECR, you can use lifecycle policies that automatically clean up old container images on your behalf. Amazon ECR also comes with vulnerability scanning options. When you push an image to Amazon ECR and it's scanned, you know whether you have any vulnerability issues with those images. With ECR, you can also connect to an upstream repository and cache images in your local ECR repository, then keep those images updated using pull through cache.
Some of the inbuilt security features in Amazon ECR are the following. Amazon ECR, like other AWS services, integrates with Identity and Access Management. This means you can control permissions for who's allowed to push or write images into your container registry and who's allowed to pull those images from your registry. Controlling who can pull from your registry is important because container images often contain your company IP, so you want to protect that IP and restrict who can access those container images. By creating the right IAM permissions, you can control that access.
For pushing images into your repositories, you want to restrict who can push because you need to ensure all images in your repositories conform to your company security profile. Ideally, you build those security checks into your pipeline as you're building the images, and you don't want people to be able to push directly into repositories because they could include pieces of code or vulnerabilities that haven't been checked. Amazon ECR uses AWS S3 for storage of your container images. All these images are encrypted at rest using an AWS-owned key with AES-256 encryption built in, and we don't charge you any extra for this.
If you decide you want to control that encryption yourself, you can use your own KMS key with ECR to do that. Amazon ECR also supports the use of private VPC endpoints. This means any data transferred to and from your registry does so without leaving the AWS network itself. If pulling down container images is the only type of access you need, you don't actually need a NAT gateway or an internet gateway from your VPC. I mentioned that Amazon ECR helps with vulnerability scanning. There are two types of vulnerability scanning with ECR.
Back in 2019, we released a basic scanning option for Amazon ECR, really just to encourage our customers to scan images. This was based on Clair, an open source vulnerability scanner, and it scans for OS vulnerabilities only. Recently, we updated that to use Amazon's own proprietary native technology, which goes across more operating systems and more up-to-date operating systems. By default, all new registries are opted into this Amazon-owned scanning technology.
So what happens when you push an image to ECR? When you push an image, either you or the pipeline pushes an image, the scanning technology kicks in and scans that image for any OS vulnerabilities. Any results that conflict with any open CVEs are returned to you within the ECR interface. But if you want to take your scanning to the next level, you can opt into enhanced container scanning, and this is where Amazon ECR integrates with Amazon Inspector.
Amazon Inspector not only scans for OS vulnerabilities but also for application package vulnerabilities as well. With the Inspector scanning included, you can not only scan your standard images, but images that are built from scratch, distroless images, and Chainguard images—all of these can cause problems with more traditional vulnerability scanners. When you or your pipeline pushes an image to a registry that you have opted into enhanced scanning, Amazon Inspector kicks in and scans that image for any application and any OS vulnerabilities.
What it then does is prioritize those findings and send them to AWS Security Hub . This is important because it now gives you an audit trail to follow, and that's a critical component for a lot of our customers. If there's an exploit available, it will tell you about the image. If there's a remediation available for the exploit, it will also tell you that. And it will scan for end-of-life software and tell you that as well.
In addition to the enhanced scanning , you can tell it that you want continuous scanning. Continuous scanning means that whenever any new vulnerabilities are added to the Inspector vulnerability database, your existing container images are also checked to see if they are affected by those vulnerabilities. If your images that you've already deployed and used in the workload are affected, you want to know which of my clusters is that running in and what part of the cluster is that running in. It's no use knowing about vulnerabilities if you don't know where those images are running.
With the integrations with ECR and Inspector now with both Amazon ECS and Amazon EKS, it will tell you where those affected images are running down to the task and pod level in your clusters. So you not only know you've got affected images, you know where they're running. That brings us on to signing your images . You may think that because you built your image and you scanned it, then you're good to go. But code signing is an industry standard technique to ensure that the code that you checked is the same as the code that you run.
As I mentioned during the container supply chain, you can decide to integrate AWS Signer in your pipeline as you've built the image to sign that image, so that you know that it is unaltered from when you built it. But with that, you have to build that integration into each and every pipeline. Now, I'm excited to be able to tell you, we launched this last week . The Amazon Elastic Container Registry now has fully managed container image signing that integrates with AWS Signer . You can enable this with just a few clicks in the console or a single CLI command, and now you've got a centralized image signing tool so you don't have to integrate in each and every pipeline.
If you want to reconfirm your image before that image is then deployed onto your workload, and I strongly suggest that you do that.
Amazon ECR also stores the signatures from your signed images alongside the images in the registry. With Amazon EKS, you can use a combination of Gatekeeper and Ratify or Kyverno to detect that an image about to be used in the EKS cluster has a different signature from the one that was confirmed as good to go, and it will stop that. With Amazon ECS, you can also use lifecycle hooks combined with Lambda. With that, you can check—and we have a guide as to how to do this—you can either say, "Okay, I know that image doesn't match the signature, I just want to be notified about it," or you can configure it to block those images from being used in ECS as well.
Runtime Monitoring with Amazon GuardDuty and Session Wrap-up
It is really important for you to think about combining this with your container pipeline. I also mentioned monitoring your running images for unusual or suspicious behavior, and this is where Amazon GuardDuty comes in. Amazon GuardDuty supports runtime detection for both Amazon ECS and Amazon EKS. It looks for any unusual behavior, such as your containers trying to connect out to the IPs of known Command-and-Control servers to make them part of a botnet or Bitcoin mining, unless you are actually Bitcoin mining in your container workload. It is also looking to see if your containers are trying to exfiltrate data out of your solution. You want to know about this, especially if it is exfiltrating data that you did not expect it to be.
You can enable GuardDuty for all of your clusters or for a subset of your clusters on both ECS and EKS. I would like to come to some key takeaways from this session. Amazon ECR stores and transmits your container images securely. It also enables you to both scan your images for vulnerabilities and to sign your images. Your security posture and your security profile needs to be continually evolving as security attacks evolve. You should always think about whether you can integrate signing into your container workload so that you can attest that the images you have decided are good to go from a security point of view are the ones that are actually running in your solution.
We have some other sessions that are running at re:Invent, quite a lot of sessions actually, but these are some security ones. We have EKS and ECS ones here, workshops, builder sessions, and short talks. If you are new to containers and you want to learn about ECS or EKS, we have two training programs. These are digital badges, and they take you from knowing nothing about container images through to knowing how each of the services is built up and how you need to think about those services. These are self-paced, so you can go at your own speed. At the end there is an assessment that if you do the assessment and pass it, you will get a digital badge that you can then share with your employers and your social network. These are all free, and you can do this on our training platform.
We have put together some session resources, so all of our container sessions are linked in a Git repository. If you scan the QR code, you will be taken to a Git repository that has additional resources for all of our container sessions. It will also include some additional resources from this container session. Hopefully it was not too painful to come to the last session of the day at this theater. Thank you for coming, and please fill out the session survey in the app. Thank you!
; This article is entirely auto-generated using Amazon Bedrock.
Top comments (0)