Shadow IT isn’t a new thing. Any large corporation has seen it. Sometimes called “server under desk” or “production desktop”.
Sometimes it grows out of a personal project that started on a spare machine and that gradually morphed into a mission critical machine… but without any of the controls and tools normally associated with production infrastructure (patches, backups, DR, access admin, security scanning…).
Other times it grows out of a desire to do things quickly; all of those controls and tools take time and can hinder the developer experience.
From Twitter came this gem:
This is a cute way of helping people understand the difference between the three concepts. It also helps start to drive conversation around remediation activities and risk assessment.
(Let’s not get too tied down with interpretation; all analogies have holes :-))
What if the door was a bedroom door, rather than a house front door? How does this change the probability of a bear getting in and thus getting mauled?
I’ve spent a few posts talking about the ecosystem required to keep a container secure; hands off automation, code provenance, and the like.
But a number of people have asked me about the techology. Mostly they talk about “docker” and the security concerns. I’ve been loathe to talk about technology specifically because it changes. Yesterday docker daemon runs as root; tomorrow it may not. Yesterday the kernel exposed a problem, tomorrow it won’t.
A decade or so back, VistaPrint did a “free card” offer as long as you used one of their templates. So I got a bunch of cards printed
Over the years I’ve probably given out…5 of them? Heh.
VistaPrint no longer seem to do freebies, but I decided to refresh my image.
The cost was $8 for 150 cards or $9 for 250, so I went for 250. And then after checkout they said for $1.
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.
Identity and Access Management (IAM) historically consists of the three A’s
Authentication What acccount is being accessed? Authorization Is this account allowed access to this machine? Access Control What resources are you allowed to use? On top of this we may also need to consider
Auditing Log the attempt to use the machine Provisioning How does the account get onto the machine?
In a previous post I showed that if you stop treating containers as if they were VMs then container security is easy.
Now we need to look at how to keep the contents of containers safe.
In general there are a number steps:
Build good containers Scan existing containers Replace bad containers Build good containers This should just be an extension of your existing source control process; your CI/CD process; your “test driven” processes.
People think container security is hard. But it’s not… if you think about it the right way. And that’s where people tend to go wrong, and that’s why they think it is hard.
So let’s follow a thought pattern…
First we need to consider what is a container and what distinguishes it from a virtual machine.
In general a container has the following properties:
Shared kernel Segmented view of resources Separate process ID space Separate filesystem mount space Separate IPC memory segments Separate view of the network … Multi-platform Linux VServer (from 2001!
It started with a set of slides by a friend:
My first thought was to wonder wonder how heartbleed, shellshock, cve-2015-7547 and the like fit into this story. He answered “rebuild the world and redeploy”. Which I felt missed the problem.
You also need a level of control around what goes into containers, who can build containers, where they get deployed.
We have decades of history of knowing that self-run machines are badly patched and badly maintained; if the bug isn’t in the application code then it’s mostly invisible to the developer.
My old site was nicely hand crafted HTML. Each bit loving created. It worked… but it did smell a little 90’s. Which doesn’t surprise me; the last time I did any web development was the 90s!
So I thought I’d try something a little more modern.
Unfortunately most CMS systems (eg WordPress, Joomla, Drupal) appear to want to use a database of some form. The content is displayed dynamically based on the user request and the database content.
