Container Security
Start course

This course is for anyone with a basic understanding of what containers are, and even why you'd want to use them, but who doesn't understand the nitty-gritty of how they work yet. You should have a basic technical literacy, as well as an understanding of cloud app architecture. In this course, you'll learn about the major concepts around containers. You'll learn about different container systems, learn all about orchestration, get a better understanding of how and why to build and run 12-factor apps on containers, container security issues, and you'll even get a quick look at how to get a microservices app up-and-running on your computer in about two minutes with Docker compose.

Course Objectives

  • Understand the options for running containers
  • Understand the common security concerns
  • Know why orchestration is important
  • Understand what types of applications should be containerized
  • Understand how logging and monitoring works with containers

Intended Audience

  • Project Manager
  • Business Manager
  • Developers


A good prerequisite for this course is to take the Introduction to Containers course.

This Course Includes

  • 47 minutes of high-definition video
  • Console demonstrations

What You'll Learn

  • Course Intro: What to expect from this course
  • Microservices: Designing Microservices and 12-factor apps.
  • Running a Microserve App on Compose: Demo of using Compose.
  • Container Orchestration: What is orchestration and how does it work?
  • Container Security: Best practices to make containers more secure.
  • Container Logging and Monitoring: An overview of tools commonly used for monitoring.
  • Container Systems and OSs: Different Linux Containers: LXC, Docker, rkt, OCI, and an overview of Windows Containers.
  • Wrap-Up: Course summary



Using containers in production introduces a new set of security concerns into play. In this lesson, we'll talk about those and how to mitigate some of them. To be clear, we'll be talking about container-specific security. Obviously, your code should follow best security practices as even the best secured physical server won't prevent someone from accessing your database if you don't sanitize your user inputs.

First, let's be clear, a system built with containers is on the whole, less secure than one built with virtual machines. Virtual machines have a hypervisor layer through which all commands and data must pass between the VM and the host machine. Containers, on the other hand, use the underlying kernel of the host machine to run commands. 

As such, even with the security features baked into the Linux kernel, there is no way to 100% lock down the container from the kernel, and anyone with root access to the host kernel will be able to peek into all of the containers running on that machine.

But all is not lost. After all, containers can run inside VMs. So if you really wanted the operational benefits of containers but the security benefits of VMs and performance isn't your number one concern, you can just run your containers inside VMs on the host. This gives you the security, but also the poor performance of a hypervisor layer, but all the other benefits of Docker.

As an example, this is how AWS container services work. You run the containers inside EC2 instances which are just hypervisor VMs running on AWS's physical servers. In addition, companies like Intel and VMware are working on building very fast container-focused VMs to minimize the performance impact while getting all the security from the VMs.

However, more and more companies are finding that this isn't necessary. Rather, as the attack factors for containers apps are discovered and secure, container apps are becoming more secure to run on bare metal. For instance, IBM's Bluemix cloud hosting, an AWS competitor, lets you run containers directly on their cloud servers. Regardless of how you run your containers, there are some security best practices to follow. The first and perhaps most important is to only run verified images so that no attacker can inject their image into your system.

The best way to do this is to have an image registry for your company which lets you build, share, track, and run your images. An image registry is kind of like GitHub but for container images. Image registries like Docker Hub and Docker Trusted Registry implement a tool called Docker Content Trust which lets you sign your images and define exactly what images are allowed to be run on your system. In addition, there are security scanning tools like Atomic Scan and Docker Security Scanning which you can run on your images once they've been built.

These can be automated and implemented as a part of your continuous integration or testing processes. They give you a bill of health for each image, letting you know if they have any known vulnerabilities. When creating your images, it's important that they follow the principle of least privilege. The container should have the least amount of privileges it needs to do its job. For many containers, this means implementing read-only file systems.

Even if an attacker gets full access to that container, they won't be able to write anything to the underlying system. In addition, you can do things like limit resources for each container so they can't be hijacked for other purposes. And of course, don't run your processes in the container as a root user. Finally, there are runtime threat detection systems that you can look into like Aqua Security and Red Hat OpenShift. These take a baseline of what your system should look like and moderate it to make sure that nothing out of the ordinary happens.

If it seems unusual activity or traffic, you can set up rules so they alert you, shut the system down, or take other steps. This way, if an attacker gains access to your system, you're more likely to notice right away. Containers still aren't the most secure system, and for certain incredibly high risk applications like healthcare data, they might not be right. However, for most apps there are simple steps that you can take to secure your system just as well as any other production environment you're likely to use.

About the Author

Adrian M Ryan is an educator and product manager. He was an early employee at General Assembly, has co-founded an education startup and a consultancy, and he loves teaching. He grew up in rural Alaska, and while he now lives in New York City he makes sure to find time to get out in the woods hiking whenever possible.