Subscribe / Unsubscribe Enewsletters | Login | Register

Pencil Banner

12 ways to improve run-time container security

Gary Duan, CTO, NeuVector | May 17, 2017
Checkpoints spanning from simple preparations to more advanced run-time security controls.

This vendor-written tech primer has been edited to eliminate product promotion, but readers should note it will likely favor the submitter’s approach.

There still really aren’t many enterprise run-time security tools for containers available, which has skewed the conversation toward establishing defensive barriers prior to run-time – during the build, integration, and deployment stage.

Of course, with rapidly evolving technology like containers, it can be all too easy to overlook the most basic security concerns, so, really, any focus at all is welcome. Efforts pointing out the security advantages of digitally signing container images at build time, and scanning them before they are pushed to the registry, should indeed be heard. The OS should be hardened and attack surfaces should be trimmed where possible. Solutions like Seccomp and AppArmor that introduce security profiles between containers and the host kernel ought to be implemented.

However, the reality is that the idea of thwarting all hacking attempts by simply putting in place preventive measures prior to deployment is unrealistic. Truly guarding against all such intrusions requires security with the ability to detect threats and violations at run-time. Considering the number of threats occurring in real-time with working applications, run-time security is arguably the more crucial component of an overall container security strategy.

Container deployments can suffer from most of the same threats common to virtualized or single-OS server environments, in addition to a few new ones. General threats to container security include:

  • Application level DDOS and cross-site scripting attacks on public facing containers
  • Compromised containers attempting to download additional malware, or scan internal systems for weaknesses or sensitive data
  • Container breakout, allowing unauthorized access across containers, hosts or data centers
  • A container being forced to use up system resources in an attempt to slow or crash other containers
  • Live patching of applications to introduce malicious processes
  • Use of unsecure applications to flood the network and affect other container

And here are some examples of prominent container attacks to prepare for:

  • The Dirty Cow exploit on the Linux kernel allowing root privilege escalation on a host or container
  •  MongoDB and ElasticSearch ransomware attacks against vulnerable application containers
  •  OpenSSL heap corruption caused by malformed key header and a crash caused by the presence of a specific extension
  •  Heap corruption and buffer overflow in Ruby and Python libraries allowing execution of malicious code
  •  SQL injection attacks that put hackers in control of a database container in order to steal data
  • Vulnerabilities like the glibc stack-based buffer overflow, giving hackers control through the use of man-in-the-middle attacks
  • Any new zero-day attack on a container that represents an on-going threat
  • To understand why run-time security is so critical, consider the application lifecycle. What’s developed, tested, packaged and deployed in just months will often run for years, and may be shared across millions of instances worldwide. This makes run-time by far the greater window of attack.


1  2  Next Page 

Sign up for Computerworld eNewsletters.