Cybersecurity in Retail Podcast: Docker containers and future trends

Publish date:

A cybersecurity discussion around containers and docker containers

In the 3rd edition, three cybersecurity experts Peter Hansen, Lee Newcombe and James Relph discuss containers and docker containers – the benefits they bring from a security aspect; the difference between containers and Virtual Machines (VMs); move towards micro-services; and other future trends. Have a listen.

Transcript

Peter Hansen:

Welcome to this third episode of the Capgemini Cybersecurity Podcast Series, where we are discussing security aspects in regards to the retail industry. In episodes one and two, we touched base on the threat landscape of the retail industry and the challenges of cloud adoption. I’m your host, Peter Hansen, and today we are focusing more specifically on the security aspects in regards to usage of [Dockers] and containers. With me from the UK is, once again, Lee [Newcombe]. Hi Lee.

Lee Newcombe:

Hi Peter. Nice to be back.

Peter Hansen:

Welcome back. And in addition to Lee, welcome James.

James Relph:

Hi Peter. Thanks for having me.

Peter Hansen:

Fun facts. Lee, do you have any fun facts for us?

Lee Newcombe:

Yeah, kind of fun. I was doing a bit of research before we started today and I looked up the number of CV entries, so common vulnerabilities and exposures, so the number of vulnerabilities that have been found in Docker. Since 2014 there are 53 entries in the CV database related to Docker. That compares to 33 for VMWare ESXI during the same time frame. Not ascribing any value judgments to those numbers, I just thought they were quite interesting, and fun, and definitely facts.

Peter Hansen:

Thank you, Lee. So, James?

James Relph:

I’m going to go a bit lighthearted for fans of 90s sci-fi, and that is that Kubernetes itself is based off an internal Google project that was called Borg. And the seven stakes on the Kubernetes logo are a reference to the Seven of Nine character from the Star Trek Voyager series.

Peter Hansen:

Okay … And I found some facts about the Docker hub database breach. So, it was actually breached in the end of April this year and approximately 190,000 accounts may have been exposed. So, just because it’s Dockers and containers doesn’t automatically mean it’s safe.

So, going into the subject, James, what benefits do you see containerization bringing from a security perspective?

James Relph:

There are quite a few different benefits. One thing I’ll just say to start with is that these … And I think when most people talk about containers these days they’re talking about Docker-type containers. There are other kinds of containers now. I was using containers back on Solaris in 2009, around about then, and they’re quite different. But Docker containers have some specific kinds of weird thing in the way they work, and I think there’s two strings to the benefits which they give.

Firstly, from a technical perspective, Docker has only one process per container model. What that means is you can have actually strong isolation between different processes. So, previously if you had a server of VM with lots of different processors running, you might be running lots of different Tomcat instances on there. For instance, a breach in one could potentially lead to vulnerabilities with the others. Docker helps by kind of breaking that up, so each process lives in its own little bubble. You could do it in VM, but obviously there’s a lot more overhead involved with that.

The other thing is there’s the container model of only including the [binaries] and libraries that are required to run an application, which reduces the overall [attack] surface. And coupled to that there is that smaller size makes those components easier to scan and easier to secure.

I think the main thing that pushes security with Dockers are actually some of the changes in development and operations culture and practice that drives [inaudible]. So, things like one process per container model. That has to be picked up by the teams. But if they do that it does help in separating content out and it pushes the microservice design, which again kind of helps on the security front.

Docker containers also give an easy way to update things. So, if you have a dock file and you’re pulling in from a [better bunted] version for instance, it’s quite easy to update the type when vulnerabilities are discovered. And it puts tools and the actual how things are going to run in production in the hands of the delivery teams very early on, so it shifts things [left]. So, they can build and test with the same configuration and things that will be used in the production environment.

Peter Hansen:

So, do you have anything to add to that Lee?

Lee Newcombe:

I think the only thing I’d say really around containerization is I think there is still a little bit of a misconception out there at times where people do conflate containers and VMs. Containerization is not [virtualization].

Mike Holman published a blog post back around 2016 I think, which kind of explained how he views that difference between containerization and VMs. So, he views virtualization as living in a house. You have much more control of your boundary. Whereas containerization is if you’re living within an apartment block, so you have much more reliance upon shared infrastructure. So, in his apartment-block analogy you have shared plumbing, shared power, et cetera, so you are more likely to be aware of interference from your neighbors in that kind of apartment block than you are with the house model. And I think that’s true when it comes to security as well, so you have to be aware that with containers you do still share that base operating system. So, there is still that risk of interference from other tenants on that operating system as well.

But I do take on board all the points that James made as well because I do like the way you reduced your attack surface by minimizing the number of interfaces and dependencies in the [UX] that you need to consider when you start containerizing your applications.

Peter Hansen:

Yeah, I agree to that as well and that containerization has a lot of advantages. What I don’t like is that people tend to believe that all control goes out to the developers. We even had one of the big players within containerizations presenting to us who said straight out that in a few years we don’t need server ops because the developers can do everything. So, would you agree to that, James?

James Relph:

No, I don’t think that’s true personally. It’s quite interesting because I think containers have shifted a lot of responsibility, and I think they do work well with the dev ops model itself in having cross discipline teams who are aware of how things work from both side of the fence to some extent.

But part of the problem I’ve seen, and that actually follows on from what Lee was saying there, is that a lot of people don’t understand how Docker works. I do quite a lot of interviews with dev ops engineers, and when you ask them what’s the difference between a container and a traditional version machine, they’ll come back with things like it’s faster, it’s lighter, but they won’t actually know how it works under the hood. I think that’s important to know to use Docker successfully. I think there’s a lot of things that you can do badly if you don’t realize how Docker differs from VMs.

The orchestration of content is where a lot of the value’s coming at the moment, so using things like Kubernetes. Kubernetes is a big system by itself. It’s not from my experience the kind of thing that developers would want to get involved with. It’s the kind of thing that does fall to more traditional platform teams to build up their skillset around that and to manage that. So, I don’t see them replacing or removing ops from the overall structure. I think you will still have people who need to know how things work, that delivery teams won’t need to be aware of. And while some of that gets abstracted, the tools that allow that abstraction like Kubernetes themselves, they’re quite big things to run. It’s not just a case of oh, we’ll fire up the Kubernetes cluster and that will be suitable for our production environment.

Lee Newcombe:

And security teams can help as well by giving developers the tools that they need, especially if you are starting to think about moving towards dev sec ops. So, there are tools like the run-time application self-protection tooling that can help, and also things like cloud workload protection platforms as well, both fairly new types of securities technologies that can help to secure these kinds of containerized environments. But then it’s down to security just to say “Yes, we recognize all these new ways of working and here are tools that you can use to help you work in those ways,” rather than maybe just getting a little bit confused.

Peter Hansen:

Yeah. And one of our big global partners Trend Micro actually helped specialize products to do a scan before it’s actually being deployed. So, I think we have to redefine quite a lot how we implement the technical security controls, and also making sure that the non-technical security controls actually get adapted and definitely considered when using the technology as such.

Lee Newcombe:

That’s certainly … Just to dive in there because I can hear James getting ready to dive in, so I thought I’d go first. We have to start thinking about patching as well. So, patching and containerization, it’s a really good security benefit at that point because you don’t really need to go in and patch your running applications. You just get a new container with the up-to-date things in there and take down the old one, spin out the new one.

James Relph:

Yeah. And I think a lot of that … You do have the technical side of things that the platform team will want to get involved in, so putting those container scanning tools in. So, in the open-source world you’ve got things like [clam software], you have the commercial tools like Twistlock and Aqua that can do a lot of that work. But that’s the kind of technicalization, but there needs to be a discussion with the developers because if you let your developers just go off and start grabbing containers from everywhere and building them in the way they see fit, you’ll end up with a huge number of containers in your estate that you need to manage, you need to track, and even to patch.

I think one of the things we’ve been trying to do recently on my project is actually just to cut down the number of different base containers and [inaudible]. These are the ones we’re going to use. We should agree on these. And also, make sure people are picking the right containers. Because quite often people, they’ll see everyone using Alpine. Alpine’s a really popular container base image because it’s very small. So, they’ll pick it and then that’s great but I need all these extra tools into it. So, by the time they’re finished putting their Docker file together it’s going to be 300 lines long and the little Alpine image now has hundreds of extra dependencies they’ve pulled in. What that means is instead of just updating your Docker content when there’s a new release, they’ve actually then got to go through all their Docker files and make sure actually now this SSH version we’re pulling in needs updating, and these are the set of libraries we’re pulling in here, and all these things we’re doing with an APK install, they all need updating now manually. So, you’ve got to have those kind of discussions with the delivery teams to make sure that they know how they should be putting things together and that you’ve got some alignment between the teams on what they’re using.

Lee Newcombe:

Yeah, and I think that is a common theme through all the different podcasts, is that need around governance and making sure that people know what they should be doing, having the common set of principles out there, because otherwise you’ll end up with various forms of sprawl, either VM sprawl, or container sprawl, or SaaS sprawl. You’ve got to have some way of maintaining the level of control, and that in this kind of dev ops environment has got to be a joint endeavor.

Peter Hansen:

Yeah. I mean, the need for standardization, and control, and [inaudible], et cetera, that doesn’t really disappear just because it’s another technology.

So, we are actually almost at the end of this podcast. I would like you, James, to do some closing remarks about where this is heading in terms of container and microservice.

James Relph:

I think it’s definitely driving the shift to microservice. I’ve seen that from a few different projects I’ve been involved on recently. I think teams and businesses to some extent are starting to realize that it fits that model nicely and it allows them to iterate quickly, which is obviously becoming more important. That’s more visible for businesses to get that ability to quickly get features [inaudible] into production.

I think at a technical level then it’s some interesting stuff going on around things like Micro VMs. So, AWS released Firecracker last year, and it’ll be interesting to see whether that goes, because it is possible that we’ll move slightly away from the containers, more to potentially containers within Micro VM. So, you actually kind of ramp up the separation between the different processes by running them inside a Firecracker VM. That kind of approach is something that I think I’ll be watching for a little bit and we’ll see what happens with that.

Peter Hansen:

Thank you James. And Lee?

Lee Newcombe:

I think there is that other elephant in the room at the moment, which is around [functions] of service. So, things like Amazon Lander, [inaudible] functions, we’ve got cloud functions. And if you’re going to go down that microservices route, do you want that kind of pain of building your own Kubernetes Docker infrastructure or do you want to go off and buy the one that’s pre-built, et cetera, things you can do at the moment with the containerization you can’t necessarily do with service at the moment. But I do feel that the conversation’s very similar to the conversations we were having around 2009, 2010, in terms of “Do I keep all my workloads on premises or do I let them go to the public lab?” It’ll be interesting to see over the next few years as to how that conversation ends up.

Peter Hansen:

Thank you. So, from me Peter, as well as James and Lee, that’s all we have time for today on this episode where we are focusing on the retail sector and some of the challenges that is presented for them. I would like to thank you Lee for once again joining me. Thank you.

Lee Newcombe:

Thanks Peter.

Peter Hansen:

And to James, to join the both of us for this episode.

James Relph:

Thank you very much.

Peter Hansen:

I would also like to thank you for listening in, wherever you are in the world. You will find future episode in the Capgemini channel through your favorite pod player. If you enjoy this, please also share with social media. Thank you.

Learn more

For more insights and analysis, tune into our Cybersecurity podcast series.

Related Resources

Electric Vehicle Charging Infrastructure Development

Will there be enough charging points to support electric vehicle rollout in the next decades,...

What is Digital Power?

Digital technology is at the heart of economic, military and cultural issues.

cookies.

By continuing to navigate on this website, you accept the use of cookies.

For more information and to change the setting of cookies on your computer, please read our Privacy Policy.

Close

Close cookie information