It matters not what conference you attend: the discussion in IT is all about containers and automation. The real question is, “Do containers change enterprise IT?” Some folks say they do in major ways, others are on the fence, and still others are having nothing to do with them. Let us look at all aspects of enterprise IT and determine what needs to change, if anything.
What follows is a set of articles based on traditional silos in IT. Containers unto themselves will not break down these silos, but DevOps, Agile, and other processes will. Virtualization started to break down these silos, yet unfortunately they still exist. If anything, I’ve observed that containers have stratified IT even more. We as IT professionals need to break through these silos. IT architects need to involve everything from these groups in all decisions. So, with that out of the way, let us look at the impact of containers on enterprise IT security.
Security
We always have to have security, and in my opinion, containers really do not change security all that much. We still have to have antivirus and anti-malware protection (to meet compliance), encryption/digital signatures, firewalls, etc. Everything we do today still needs to be done. However, what containers add is another management layer and, in some ways, another compute layer, which also need to be secured in some fashion. For management security, the effort is not any more difficult than securing a virtual environment. For the workloads, in most cases a hardened environment will suffice. Yet the question remains: “Should you harden the containers as well as the operating system running them, or should you just harden the operating system?”
“Harden both the operating system and the containers” is the answer going forward. In other words, implement Security as Code for operating system hardening, configuration, etc., as well as for container security. That said, what is container security?
Container security is ensuring that:
- No two containers can talk to each other except over specified network or interprocess communication channels.
- Each container has a blessed configuration, and you know when such containers’ configurations change.
- Each container has the proper files and libraries installed, which includes attestation of the files and libraries (using checksums).
- Role-based access controls (RBACs) for controlling a container are employed.
- RBAC for content within each container is employed.
- No container runs as administrator (or root), and each exception is documented.
If you look at each one of those items, you’ll see that they also apply to virtual machines and any process running within any guest operating system. But now we have one more abstraction, one more layer to our stack, as can be seen in the following figure and is discussed in our Substrates of IT article.
Since we are adding one more layer, we need to secure it. Now, the argument I often hear is that containers are not a new layer. I disagree: they certainly are. Management changes, as does deployment. There is quite a bit going on under the covers to make containers work. The more you abstract, the less people worry about what you are abstracting, and that is the danger from a security perspective.
If we abstract the operating system (which is what containers really do), does that imply that the security of the operating system no longer matters? Just because we use Red Hat Atomic, VMware Photon OS, or CoreOS, does that imply that our security policies are being met by those operating systems? Yes, I agree they are smaller, but smaller does not imply anything is more secure. It just implies it is different.
The benefit to using containers is not a security benefit per se. However, if we use a container operating system, our security could be simplified. We then share that security across multiple containers, but we cannot forget the underlying levels. Security becomes code applied when each container is launched. As operating systems change, as libraries change, keeping the operating system and agents in sync with each container will be an interesting challenge—yet one that is, once more, not a new concept.
Containers represent a scale of computing that is far larger than we have ever considered before: tens of thousands of containers in one application. For this, we need better tools, better security, and better ways of modeling. Lastly, is there any need to move security up from the operating system into each individual container such as anti-virus/anti-malware or can they reside in the IT Management/Agents substrate?