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.