How Contained are your Issues with Containers?

In the 1948, an American chemist named Earl Tupper introduced a new type of plastic container. It was a fantastic little object, the best thing since sliced bread. They were incredibly easy to use and could store food forever, and they became all the rage in American households. Tupperware was soon everywhere - from your mother’s kitchen, to the Simpsons.

It was just a simple polyurethane bowl, nothing fancy, but what made it revolutionary were the whimsically named 'Burping Seal' lids. Once the lid was on, it created an airtight seal that not only kept what was inside fresh, it also sealed away the food inside - odours, oils and everything else - keeping it from affecting food in any of the other boxes. They were easy to store, easy to carry, and never made a mess.

Container architecture works a lot like Tupperware.

Containers are everywhere

Everyone who wants to scale has used them, and continues to use them simply because of how convenient and useful they are. The 2019 Container Adoption Survey (by Portworx and Aqua Security) stated that over 87% of its respondents ran container technologies. Of those running applications in containers, nearly 90% ran them in production, up from 84% in 2018 and 67% in 2017. So yes, most companies use containers.However, not all those who run this tech understand how to deal with its challenges efficiently.

Problem #1: We need more security around popular deployments

Data security and the loss of data were the two most cited areas of concern, and the respondents stated that applications deployed in containers had become more complex over the years. Which obviously points to an increase in the applications’ need for security.

Problem #2: Containers face a people problem

When it comes to actually securing applications, there’s another conundrum: most respondents (just over 30%) named the organization’s security team and the DevSecOps teams as the ones responsible for patching up vulnerabilities… but 47% of DevOps respondents said DevSecOps were responsible for looking into container security, while 54% of Security respondents named Security as the main owner. So there's clearly a lot of confusion about who should look into securing containers in an organisation (on the bright side, this trend is better than either team evading responsibility)... which means when something goes wrong, nobody really knows who should fix it.

Problem #3: Containers have changed the security paradigm

The growing almost mutating need for containers, has also ushered in the need for security in this tech to evolve as well. The problem here is 3-fold:

1. Automation across SDLCs needs security checks at every point: Because containers keep all their dependencies contained, they can easily be shifted from a development environment to a test environment, and then a production environment. While this makes it easier for faster deployments, it also means that every part of the SDLC also has to have security intact. One vulnerable link and the deployed application is open to an attack.
2. Scaling containerised applications means deployed entities can mutate quickly according to the need. This means maintaining security for each component individually is almost impractical.
3. Ain't nobody got time for that: When dealing with containers and an agile development cycle, developers have to make changes quicker than ever before — probably hours and days, not months. Including security into workflows could provide many advantages, but nobody has the time for it (unless it's absolutely necessary).

Because we’ve been in the business of helping organisations create and deploy secure applications, we’ve seen this ourselves. This also puts us in the position to propose a solution: holistic learning for both Security and DevSecOps teams.

The one silver bullet: Education

The way we see it there’s three ways to solve these issues via a holistic approach:

1. Educating Developers about:
2. How they can engineer secure containers
3. The risks of container security
4. Educating DevOps and DevSecOps professionals about security considerations for the deployment of containerised applications
5. Educating the penetration testing community as well as those in Application Security on the identification of vulnerabilities and potential threats on containerised deployments

But education can be hard… right?

Obviously Developers, DevSecOps people and those working on Application Security all need different levels of education on how to treat these issues… which is why there is no comprehensive course that could be relevant for them all.Moreover, topics such as these are learned most of the time, via hands-on experience… Which is why we decided to address these issues in separate courses designed to give you first-hand experience, not just theoretical knowledge.Our courses have a number of added edges over those widely available, some of which include hands-on cyber ranges where you can explore the various attack possibilities and hence come up with defence strategies, a full fledged deployment of Container Registry and defences, Container Security Engineering (both of which are rare), and the use of monitoring for containers with OSS tools like OSQuery.The aim with our courses was to help attendees get trained in time-tested approaches to building, running and security testing container deployments, even on platforms like Kubernetes. We even have a Kubernetes Security Masterclass where attendees start with setting up a Kubernetes cluster, attack the cluster and learn to effectively secure Kubernetes clusters through multiple deep-dive examples and cookbooks!If you’d like to take a look at our courses on containers no matter which level of learning you’re at, visit Container Security and Orchestration training we45 for yourself!