back to article Containers rated more secure than conventional apps

Containers are more secure than apps running on a bare OS and organisations that like not being hacked therefore need to seriously consider a move, according to analyst firm Gartner. Analyst Jeorg Fritsch, in a new document titled How to Secure Docker Containers in Operation says “Gartner asserts that applications deployed in …

  1. kdd

    The only problem with containers is they don't store data very well-- they're designed to be read-only, which is what gives them their better security, so you have to store stuff elsewhere, and that's where the weak link is.

  2. Nate Amsden

    big caveat there

    Anything will be more secure if you "do it right", whether conventional/legacy or containers. Many conventional/legacy systems could be much more secure without even thinking about containers but generally companies are too understaffed or under equipped to handle changes in the face of everything else that is going on at a given time.

    For the vast vast majority of use cases simply having single use VMs is more than adequate, a reasonably secured base OS with one app running in it (along with whatever base services you might need e.g. ssh, splunk agent, monitoring agent(s) or something). The overhead is really minimal.

    Of course there are crazy people out there that want to be spinning up and down constantly, which is just overkill for just about everyone else. Most workloads are not very dynamic in nature(coming from someone working in more or less SaaS services for the past 13 years across many companies, none of which I would consider were using "legacy"(or "conventional") applications).

    Some people like to THINK they are dynamic but in most cases the amount of variability isn't very extreme at all to warrant overhauling everything for a fully dynamic environment(which is a massive investment).

    There are exceptions for everything of course, no one solution fits every problem.

    I do use containers BTW, in production even(for about two years now with good results). Though the containers are generic LXC containers(that to a system admin look more like a VM than what one might consider a "container"), not docker. Looking to expand on the use cases of containers after the success we have had. The main benefit of containers at my org is to be able to oversubscribe a host and have the containers be able to instantly scale up and down(because they have no restrictions on CPU) based on load(while removing overhead of a hypervisor and licensing costs of hypervisor). Of course we use only similar application loads for a given container host, and we have data that shows the likelihood of one system overwhelming all others on the host has never shown to be a threat in the past 5 years(or anywhere close to one).

    For everything else it goes in vmware which is of course far more flexible with networking, storage, and resource limits.

    1. Charlie Clark Silver badge
      Thumb Up

      Re: big caveat there

      Because one thumbs up wasn't enough!

    2. uqrxur

      Re: big caveat there

      When the comment brings more useful information than the article...

      1. diodesign (Written by Reg staff) Silver badge

        Re: uqrxur

        Well, that is half the point of the Reg comments section. People working in the field sharing their knowledge and experience. It's appreciated.

        C.

  3. Charlie Clark Silver badge

    Pile of poo

    If the comparison with bare metal then it's just a straw man. Containers are competing with VMs and these do have better security because of CPU support.

    The only thing containers really provide is better performance on systems with low I/O. Though trying to turn everything into a "microservice" is a one way to reduce any such improvements.

    1. Lusty

      Re: Pile of poo

      Containers don't compete with VMs, they live inside the VMs. The VM layer is there to abstract the hardware and make maintenance of the host easier. Containers don't do all that stuff well if at all, they are primarily there as an easier way to get to micro-services architecture. Unfortunately the side effect of that is making the infrastructure considerably harder to do well, so overall support effort remains static between dev and ops, just the effort moves from one to the other.

  4. Mad Mike

    Never really rated Gartner

    Yet again, another example of something from Gartner that makes no sense.

    Yes, anything 'done right' is always going to be more secure. Doesn't matter whether it's containers or simply securing an operating system correctly. Indeed, most security issues come about due to something not being done right.

    The principle draw of containers is that it allows you to run multiple containers (apps or whatever) on the same OS and therefore avoid overheads with VMs around multiple OSs etc. However, the massive downside is that if the app in one container is compromised, there must be a risk to the other containers. As has been proven many, many times, containers or OSs or whatever have many, many security holes in them. This also applies to hypervisors as well. Look at the long and shocking list of potential exploits on Xen, including such wonders as guest privilege escalation etc. The reality is that if you run multiple things together, a compromise in one will always risk the others.

    Statements like this are part of the reason why security is such a nightmare at the moment. It trivialises the issue. Senior managers looking at this will think....'I'll just chuck my internet facing stuff in containers and my security issues are over'. Everyone knows good security is about implementing lots of technologies, all operating together to catch different risks and make any compromise difficult to exploit and move around with. Containers may help and be one part of that, but many other things are far more important, which the article completely misses.

  5. Anonymous Coward
    Anonymous Coward

    Let's pretend I am new to all this ..

    What's the differences in the progression:

    1) Bare metal machine running OS running app(s)

    2) Bare metal machine(s) running VMs running OS(s)s running app(s)

    3) Bare metal machine(s) running VMs running OS(s)s running container(s) running app(s)

    ????

    I get a container is a selfcontained instance of an OS - so that there's no inter-process communication. But surely that could be delivered by a single-app VM ?

    Sell it to me ......

    1. Charlie Clark Silver badge

      Re: Let's pretend I am new to all this ..

      I get a container is a selfcontained instance of an OS

      It isn't. It's a more like a child copy of an OS. This removes the overhead of virtualisation and makes provisioning almost instantaneous. You have a lot of flexibility when it comes to the software and within the container you do have IPC, though as this tends to complicate things, you tend to have one container per process (they can be deployed anywhere).

      1. Anonymous Coward
        Anonymous Coward

        Re: It isn't. It's a more like a child copy of an OS.

        Ah, so closer to an instance of a class in programming ?

      2. Lusty

        Re: Let's pretend I am new to all this ..

        "(they can be deployed anywhere)"

        They certainly can. Stability, however, is a different matter. I tend to suggest to anyone doing it in a real environment that they match the host version to the container libraries. Running Ubuntu libraries from three years ago against a brand new CentOS kernel is lunacy yet is exactly the scenario many people get into with the "runs anywhere" attitude. Executables on Windows will usually run on any version of Windows, until they won't. Docker guarantees nothing in this respect, yet many people repeat this mantra for some reason. The portability of containers is mostly down to size because you don't need to transport libraries and OS with the code as you do with a virtual machine.

  6. Will Godfrey Silver badge
    Meh

    Wot?

    Can someone explain to me how adding progressively more layers, each with it's own nest of defects improves security?

    Or have we found the holy grail of bug-free code?

    1. Munchausen's proxy
      Pint

      Re: Wot?

      Forget it, Jake. It's Gartner-town.

    2. Brewster's Angle Grinder Silver badge

      Re: Wot?

      Think about it as adding multiple doors between the outside world and what you're trying to protect, just as no bank has its vault opening onto the street. Done badly, it's adds zero benefit for the effort involved. But done half-way decently it adds another lock to pick or check point to sneak past; it slows down the attacker, makes them expend more effort to reach the goal and increases the chance they might make a mistake that gets them noticed. Security is about layers.

    3. David Halko
      Thumb Up

      Re: Wot?

      I used Containers/Zones under Solaris for ~10 years... Zones/Containers are:

      - Secure, based upon Trusted Solaris extensions, very well tested.

      - Not really a Layer, OS Resource Controls make Container/Zone.

      - Open Sourced from OpenSolaris, code was vigorously reviewed

      Security is improved when Containers/Zones are:

      - Deployed on ZFS, corrupted/injected disk blocks are automatically repaired.

      - Deployed on ZFS, disk blocks in memory & disk are checksummed

      - Deployed on ZFS, disk blocks in memory & disk can be encrypted

      - Deployed on ZFS, encryption & correction from memory to external storage

      - Presented on Read-Only file system, root in zone can not inject into binaries.

      - Holding the Application, migrating a Container/Zone to a new Chassis automatically performs upgrade or downgrade of OS/Application, so only migration permissions are needed (not root in the Zone/Container.)

      - Using network presented by Chassis, Zone can't change network to promiscuous mode.

      - Running older OS's, since older OS services can be supplied by newer/supported Chassis Global Zone

      Security is enhanced with Branded Zones/Containers for legacy OS's:

      - Chassis DTrace supports runtime visibility to legacy branded OS's

      - Chassis ZFS from Chassis will auto-correct disk blocks experiencing corruption

      - ZFS encryption in Container/Zone reduces visibility to data from Chassis

      - ZFS encryption in Container/Zone secures data from Chassis to Cloud

      Various vendors tweeked Containers/Zones over the past decade to include:

      - Containers for: Solaris 8, Solaris 9, Solaris 10, Linux variants

      - Docker Support from Samsung/Joyent today and Oracle's roadmap

      The Performance & Capability benefits of Containers/Zones are outstanding, never mind security. I deployed my first applications in Containers/Zones back ~2005 because of the cost benefit (cheaper to use Containers/Zones than physical servers and still cheaper than VMware.)

  7. patrickstar

    This is about SELinux, but applies to containers as well... possibly even more so than a strict ruleset that reduces kernel attack surface somewhat. https://www.grsecurity.net/~spender/pics/mac_security_sesamestreet.jpg

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Other stories you might like