If your organisation is anything typical then you have multiple web sites and application that require authentication. If you’re lucky then you might have something like CA Siteminder, but your staff still complain about needing to re-authenticate every so often. The more times they need to login, the greater the chance of a mistake, causing a lockout and driving people to distraction. So you hatch a plan; let’s do a true Single Sign On.
“To summarise the summary of the summary; people are a problem” - Douglas Adams, The Restaurant At The End Of The Universe In a traditional compute environment we may have a lot of controls. There may be a lot of audit regulations. Organisations create a lot of processes and procedures. Want to login to a Unix machine? Better have an approved account, with the right authorisations. DMZ machines may require 2FA.
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!
