Back in Container security I said that we need to think about containers as VMs. I then looked at an easier way of looking at containers, by not treating them as VMs. Hopefully, at this point, some of you were thinking “Hmmm!”.
Finally I discussed the processes and workflows outside of the container implementation that is needed to keep containers safe (build processes, etc).
We can turn what we’ve learned on its head.
In order to build and maintain a container ecosystem we need to think of containers as:
- There is no persistent storage
- Short lived
- Anywhere from microseconds upwards
- You don’t change the running container; you build a new image and deploy that
- You NEVER LOG IN!
- If you can’t login, you better automate the builds
We need processes around the maintenance of containers:
- Build good containers
- Scan existing containers
- Replace bad containers
Why should this apply solely to containers?
Let’s look at an Amazon EC2 instance. Ideally we want to spin these up “on demand”.
We shouldn’t store stuff in the VM disk image; either use Elastic Block or S3 store or a database. For elastic compute where the same data needs to be shared, S3 or a database. Basically the data is transient.
These EC2 instances aren’t necessarily short lived; they may live for hours or days… but, really, compared to traditional compute environments this is short lived.
We could design workflows so that AMI images are not changed; new ones are built. Don’t patch in place, reboot from patched images.
And, of course, never log in. You automate your processes. Your developer teams instrument their apps.
The key to all this is proper automation.
That all sounds like what I defined as a container characteristic!
So here’s the challenge; maybe for the past decade we’ve been managing VMs wrong! We have old heavy-weight processes. This speaks somewhat to the pets vs cattle discussion, but coming at it from the other direction.
Maybe we can treat containers the same as VMs. Or, more accurately, we can treat VMs as if they were containers.