Container Danger in the Cloud

Lori MacVittie Thumbnail
Lori MacVittie
Published July 24, 2017

Report finds unfettered access to Kubernetes dashboards along with plaintext credentials to other critical infrastructure  in public cloud environs.

Most people lock their doors – at least when they aren’t home. After all, no one wants to come home and find someone lounging on their couch, watching Netflix and completely destroying the algorithms that determine what shows up in the “recommended list” by watching some genre you’d never watch. Imagine the horror.



Thus it might surprise you to learn that based on crime statistics, about 30% of all burglars use an open or unlocked window or door.

Turning our eyes to technology, we find similar “open windows and doors” in a recent report from the RedLock CSI team. RedLock is cloud-based, API-enabled infrastructure security monitoring platform that provides visibility into your cloud environment. So it’s like ADT for the cloud. Its recent report is based on its analysis of customers’ environments. Over one million resources processing 12 petabytes of network traffic were evaluated. It discovered quite a bit of security no-nos, but this one caught my eye:  

285 Kubernetes dashboards (web-based administration interface) deployed on Amazon Web Services (AWS), Microsoft Azure, and Google Cloud Platform that were not password protected. Upon further investigation, the team found plaintext credentials to other critical infrastructure within the Kubernetes systems. [emphasis mine]

The discovery of plaintext credentials is sadly not surprising. You might recall this issue was raised in early 2016 when we discussed “The New Insider Threat: Automation Frameworks.” Sadly, if you’re leaving the front door open, the use of plaintext credentials to authorize activity across container environments might constitute as much of an external threat as one inside.

Now, we could argue that perhaps these wide-open dashboards were non-critical and probably even non-production. They’re just test or dev, right? They were a POC for containerizing apps later that were merely forgotten about or not considered a threat. Except we know that these types of ungoverned environments in the cloud contribute to cloud sprawl, which nibbles up budgets and introduces risk other than that of, oh, unfettered access to a system that can be told to spin up countless systems with the click of a button.

The same report found that “14% of user accounts are dormant where credentials are active but no logins have occurred in the last 90 days”, which certain seems to provide more evidence that a good number of resources in the cloud are being left unmanaged – and likely unmonitored for activity.

Leaving even one door or window unlocked increases risk. The thing about physical security is that generally speaking, miscreants must physically test your door to determine its status. That means physical time and effort. In the digital world that requirement is gone. I can scan your systems with a script and have it send me a message detailing all the systems it found running and open for access in a matter of seconds. There’s a lower barrier to entry in the digital burglary game that makes it even more dangerous to leave just a single door open.

The slow but steady migration to cloud-based environments has had an impact on many aspects of IT. One we rarely make mention of is administration. But we should, particularly since most of them today are delivered via a web-based interface and offer up easy port 80 access to anyone looking for it. That means the security of administrative consoles and dashboards must be considered a priority. These systems are built on standard web components, many of which are vulnerable to the same security flaws as their user-facing counterparts. Whether it’s cross-site scripting or SQLi, default passwords, or backdoor entry, we must (and that’s an RFC style MUST) devote time and budget to testing and securing the management side of the systems and environments we are using to deploy our apps.

This isn’t a “new” security paradigm we’re talking about; we’re talking about basic web app security. Locking down access to web apps is something we’ve been doing for nearly twenty years now. It’s well-understood and it shouldn’t be something we blithely ignore just because it’s only dev or test.

It only takes one open door for a burglar – digital or not – to gain access to your entire house. And the consequences when it’s digital spread further and faster thanks to technology and the ease with which we can scan, penetrate, and access connected systems.

Be safe out there. Don’t ignore the security of your administrative consoles and systems.