Ceci est une ancienne révision du document !
There are a number of areas to keep in mind when it comes to securing containers that you have running on your Ubuntu hosts and their workloads. In this article, we’ll have a look at a high-level overview of the key things to bear in mind. We’ll start with a more traditional security approach first and then focus on some of the other pertinent aspects.
Host Security
If you’re completely embroiled with getting your containers running just as you’d like them to, then it’s easy to overlook the fact that you should firstly pay close attention to the host machine that those containers are running on. Clearly the security of the host that your containers are relying upon determines how much uptime you will achieve for your applications and additionally affect the number of threats that might cause issues for you.
The usual rules apply when it comes to your host machines. You will need to update packages when they become available, most likely schedule reboots for kernel updates and also ensure that a minimal number of packages are installed to help limit the attack surface.
Aside from the time-honoured package updates, you should ensure that only specific network ports are exposed, locally and publicly, and then firewall off all other points of network access. Where possible, rate limiting access to applications, and monitoring accesses via public network ports in detail, is also advised.
Limiting Crosstalk
Another area can be helped significantly with a smattering of common sense and logic.
Imagine for example that you have three containers running on a single host, each with a unique application that provides a service of some sort. It’s advisable to carefully consider how those containers might interact from an architectural standpoint. If Container A passes data to only Container B, then Container C doesn’t need access to Container A directly at all and should be isolated at both a host and an internal networking level.
Consider another scenario where you might have two upfront web servers running via two containers, and additionally a single backend database server. The front-end servers pass read and write requests back to the database and only TCP port 443 needs to be exposed to the public from a network perspective.
There are however lots of other containers running on the same host machine which shouldn’t have any visibility of the potentially sensitive database traffic being passed through the database server before being written and stored outside of the container. The recommendation here would be to use a bridge network. By connecting only our two web servers and single database server to that private network, we will successfully limit network access and provide a layer of isolation.
This means that if another container on the host is attacked and compromised there’s more layers of security potentially for the attacker to break through in order to get access to the database data.
Common Vulnerabilities
The dreaded CVEs (Common Vulnerabilities and Exploits) apply to package updates just as we saw on a host’s Operating System a moment ago and you should monitor CVEs using any of a variety of tools.
How you approach updating packages inside your containers is a different matter. There are a number of valid approaches but a strategy is definitely required and often dismissed as being trivial. As a result, ad hoc patching practices can become dangerously erratic. This is because even the very popular container images hold a surprising number of CVEs at the best of times. Indeed many packages don’t have fixes available from the vendor at the time that a container is spun up and potentially exposed publicly meaning patching is near to impossible.
The recommendation is to think carefully about what risks affect you the most. Take time to fully understand your priorities and the attack surfaces that you present inwardly and externally. Then think about how realistic updating every package for triggered alerts is and at what frequency. Choosing a tool which can automatically alert you to software updates can be a little daunting as there are a few. One such sophisticated tool which can run from containers itself can be found here (https://anchore.com/opensource) and is called Anchore.
As mentioned, not all issues with CVEs can be mitigated against using package manager updates because fixes haven’t been released by vendors. Trade-offs between using alternative base Operating Systems and using alternative applications might be required on occasion.
Locking Down Access
As all containers share the same host kernel on a machine, it’s imperative that suitable isolation is put in place to protect the host. Without the host functioning correctly, ultimately there’s only downtime which means failure to stop a successful attack on one container from performing a “container escape” will mean that other containers, and their applications, or even the host itself, might succumb to the attack.
The Linux kernel has introduced a number of clever isolation techniques over the years which we won’t look at in detail here.
You should be aware of Kernel Namespaces, however, which means Customer A can’t see what Customer B is doing if all goes well from a security perspective. Additionally, you should know about Control Groups, known as “cgroups”, which can apply strict resource quotas such as how much memory or disk access a container might be allowed.
You might want to also read up on Kernel Capabilities – which can achieve all sorts of useful access restrictions. For example, do you really want a container to be able to change the time and date on your host’s system clock? It’s unlikely!
Although we’ve just scratched the surface on this topic, you should also make sure that lesser privileged users can’t start and stop containers with permissions that an attacker can do bad things with. Leave that sort of thing to the “root” superuser alone.
Orchestration
When you’re running more than a few containers at once, it can be a little like herding cats trying to get them all to behave properly.
Many people turn to Kubernetes (https://kubernetes.io) for larger workloads, and this brings its own security considerations in addition.
In brief you should use a more sophisticated approach to network isolation than we looked at earlier, and ensure customers or applications are split up by namespaces.
You should also finely tune Pod Security Policies, which are cluster-wide, to limit crosstalk noise and additionally host access.
Finally for sensitive container scenarios, you can introduce Security Context Constraints (https://kubernetes.io/docs/tasks/configure-pod-container/security-context/) on a per Pod (one or more containers) basis.
You’re encouraged to read further in order to get cluster security working well, amongst a number of other areas.
Stronger Isolation
Despite a very high level of isolation being possible through a previous Virtual Machine incarnation of “rkt” (https://coreos.com/rkt/), the container runtime by CoreOS using KVM (https://www.linux-kvm.org/page/Main_Page), all the rage currently is Kata Containers (https://katacontainers.io/). Essentially, Kata Containers’ aim is to provide Virtual Machine levels of security protection (where true host and workload isolation takes place), and allowing containers to benefit from such protection.
Virtual Machines adopt a hardware level of isolation making attacks much, much harder than just circumventing a host machine’s kernel. By cleverly enforcing that level of isolation, but enjoying the quick start-up times, portability, and predictability of disposable containers, it is certainly a technology to pay close attention to. Stay tuned.
The End Is Nigh
We’ve barely scratched the surface in terms of getting into the detail about securing applications in your containers.
Hopefully, however, the key areas which we’ve looked at briefly will give you some food for thought about what to read up on further the next time you need to make a decision about how to approach solving a container security problem.