Practical container security issues


If you ask people what their biggest concern is about containers, it’s always security. Some 94 percent of IT professionals in the Enterprise Strategy Group (ESG)‘s 2017 Cloud Security Report worry about container security. Specifically, they’re concerned that we don’t have mature container security programs.

There’s truth to those concerns. After talking with people at several cloud conferences in the last few weeks, I’ve found that many IT “professionals” download container images without thinking. Where did they come from? They don’t know. Who wrote them? They’re not sure. Does it contain malware? Oh surely not!

Oh surely yes!

Would you install a program without knowing its provenance on your PC? On your smartphone? I don’t think so! You’re not that dumb. But, when it comes to container images for people who just want to run a generic application without building it themselves, it’s another matter.

This isn’t paranoia. The hackers really are out to get you and your little containers too.

For example, Komtech Security Center, recently “found 17 malicious docker images stored on Docker Hub for an entire year. Even after several complaints … cybercriminals continued to enlarge their malware armory on Docker Hub. … By pushing malicious images to a Docker Hub registry and pulling it from the victim’s system, hackers were able to mine 544.74 Monero, [a cyber currency] which is equal to $90,000.”

Those malicious images have since been removed, but only after Komtech estimated they were downloaded 5-million times over the last ten months.

Do you want your cloud’s containers to be mining cybercoins for some bum? I sure don’t.

Don’t install container images unless you know they’re safe. As Tim Mackey, Black Duck Software‘s senior technical evangelist said at DockerCon, “Overall security is a function of what I’ve put into my application.”

There are other worries. The company Sysdig, for a security experiment, started a single node Kubernetes container cluster on Amazon Web Services (AWS) and left its API Server port (8080) open to the outside world. Sure enough, in a few days they had raiders installing Bitcoin miners.

Just like any of your servers, in-house or in the cloud, you must lock down contanizered applications and server’s network connections with firewalls.

But, wait, It gets worse. This February, Checkpoint researchers found cybercrooks exploiting a known Jenkins vulnerability. Jenkins, a very popular continuous integration and delivery server, has about a million users. According to Checkpoint, the cyber currency miners forced the infected systems to mine 10,800 Monero, or about $3,436,776. Of course the servers were running slower, too, meaning fewer resources were available to run their lawful application.

Again, to return to a security basic, make sure your programs have the latest patches. Just because they’re on a cloud or in a container doesn’t make them magically immune to attacks.

In the same month, RedLock found hundreds of Kubernetes administration consoles without any password protection. What is wrong with you people!

Just “test” instances, you say? I wish!

RedLock found Kubernetes nodes belonging to Tesla without a password and wide open for attack. Besides raiding Tesla AWS instances for information, the hackers–if one can call them that for such a mindlessly simple attack–of course, started crypto mining.

Really, I’ve been saying for decades: Use passwords. I’d prefer if you used good ones, but any password is better than none at all.

Get the picture? Yes, there are real container-specific security issues. And, I’ll talk about them soon. But, first, for pity’s sake, take care of the security basics. Who cares if you have a fancy alarm system if you’ve let your front-door wide open?


Speak Your Mind


This site uses Akismet to reduce spam. Learn how your comment data is processed.