Kubernetes security: New tech, familiar attack vectors

Source:-enterprisersproject.com

With Kubernetes, some old threat vectors may feel new again. Kubernetes security experts say misconfigured settings and privilege mistakes are examples that can open up risk. Mind these six items

To call Kubernetes “new” is increasingly a misnomer: July 15, 2020, will mark the five-year anniversary of version 1.0 of the CNCF open source project. But it’s still plenty new to many teams and individual practitioners, with a corresponding learning curve about how to take appropriate measures to secure your Kubernetes environment.

There’s lots of good news here, starting with this: Kubernetes comes with lots of robust native security capabilities.

Kubernetes helps organizations automate the management of cloud-native applications in new ways, enabling automated scaling, high availability, and resiliency,” says Red Hat security strategist Kirsten Newcomer. “However, as noted in last year’s CNCF-sponsored Kubernetes security audit, Kubernetes is a complex system. And that complexity can lead to increased risk if not appropriately managed.” (You can read the audit’s findings on Github.)

The CIS Kubernetes benchmark is popular in the Kubernetes community for this reason, Newcomer says. “It provides very specific guidelines for hardening Kubernetes itself. The principles applied are not new, but the benchmark provides clarity to those who are new to Kubernetes on how to apply those principles to the platform.”

[ Why does Kubernetes matter to IT leaders? Learn more about Red Hat’s point of view. ]

“Kubernetes provides users with a secure, multi-tenant model to access resources like containers,” says Luis Pabon, engineer at Portworx. “Cloud providers have been doing the same thing for a decade, just for VMs.”

Pabon notes that Kubernetes provides this user segregation and isolation for these resources through the namespace concept. Our sibling site Opensource.com offers a great technical primer: Kubernetes namespaces for beginners.

“Namespaces contain resources like security keys, secrets, services, applications, and persistent volumes,” Pabon explains. “Kubernetes also uses a role-based access control, or RBAC, for finer-grain access to API objects and resources in a namespace.” Commercial platforms and third-party security tools can also give you a leg up.

[ Read also: OpenShift and Kubernetes: What’s the difference? ]

Some old-school risks to mind with Kubernetes

While Kubernetes and containers might still be new(ish) or new to you, some old-school risks and mitigation strategies still apply. Unless you’ve completely ignored infosec in the past – in which case, you’re probably not reading this – your existing security IQ will continue to serve as a foundation for some of the newer tactics and tools you might add to your playbook.

“Kubernetes changes the approach to application security in some ways, but not in as many ways as most people think,” Pabon says. “Because security comes in layers, you still have to think about many of the same things, whether you are running apps on Kubernetes or in a more traditional manner.”

1. Don’t ignore the fundamentals

An old threat vector that’s “new” again? Ignoring the fundamentals – not just in Kubernetes itself, but in your overall environments and their dependencies.

“For instance, physical security of data centers, keeping operating systems and apps patched, practicing good password rotation hygiene for cloud services, databases, and other services – Kubernetes doesn’t change these security fundamentals,” Pabon says.

[ Read our deep dive for IT leaders: Kubernetes: Everything you need to know. ]

2. Security can’t be an afterthought

That’s often closely related to another longstanding risk factor in IT security: Treating security only as a final step in a software delivery pipeline, or something to be addressed only when things go wrong.

Unfortunately, one of the carryovers from the previous generation of design is security [as] an afterthought,” says Maksim Yankovskiy, VP of engineering at Zettaset. “This was prevalent in part because security was complex, intrusive, and performance-degrading. Legacy systems were not engineered with security in mind; it was added later, in stages, in most cases to address bare minimum regulatory and compliance requirements.”

That approach didn’t cut it in the past, and it’s certainly not going to cut it in an era where more distributed models of infrastructure (such as multi-cloud and hybrid cloud) and decoupled applications (built in a microservices architecture and run in containers) are increasingly prevalent. That’s why concepts and cultures like “shift left” and DevSecOps have been part of the IT conversation for several years and counting. Security as an afterthought is as risky as ever.

“[Security as an afterthought] resulted in unfortunate practices such as overly permissive access policies, application services running under privileged accounts, little or no separation of duties between data administrators and security administrators, and last but not least, misconfiguration of security systems where enterprise key managers that were designed to store and manage millions of encryption keys were deployed in corporate environments, but multiple applications and databases all used the same key to encrypt their data,” Yankovskiy says.

If this describes your security culture, Kubernetes itself won’t save you. Nothing will, aside from changing your overall approach. In fact, one of the characteristics of successful Kubernetes teams is that they take security seriously.

3. Mind your privileges and configurations

Encrypting different databases with the same key? Still a bad idea. Daisy-chaining your passwords across multiple cloud providers? Ditto. Playing fast and loose with your user privileges? That’ll still be a problem in Kubernetes.

That’s where native controls like RBAC come into play. They’re strong security defenses, but a common mistake teams make is to assume they’re properly configured by default. (They’re not.)

[ Kubernetes terminology, demystified: Get our Kubernetes glossary cheat sheet for IT and business leaders. ]

This is another “everything old is new again” consideration for Kubernetes users: Misconfigured settings have long been an attack vector, and they remain one with containers and Kubernetes, especially when a team’s learning curve is at its steepest.

“Misconfigurations are still a primary concern with k8s, as they are with traditional apps and infrastructure,” says Sam Bisbee, chief security officer at Threat Stack. “With k8s in particular, organizations are still learning how to run k8s, which makes it easy to make mistakes that can increase risk.”

To be sure, containers and Kubernetes do come with some new considerations. Misconfigurations are a fundamental risk no matter the application or environment; what might be misconfigured may be new or different with Kubernetes.

“There are still going to be the obvious misconfigurations, but k8s will also open the possibility for completely overlooked configurations if organizations don’t realize the interplay between their cloud provider’s infrastructure and their k8s orchestration layer and their containerized workloads in k8s.”