Today, if you’re creating or working with cloud-native applications, you’re almost certainly working with Kubernetes. According to a recent CNCF report, 96% of organizations are either using or evaluating Kubernetes. Kubernetes already has 5.6 million users worldwide, representing 31% of all back-end developers, and it’s rapidly becoming the de-facto operating system for cloud applications.
Kubernetes usage continues to grow year over year, and as the amount of sensitive data on the platform grows, so does the incentive for attackers to exploit it. It can seem very daunting to try to secure totally new environments, but the vast majority of the security issues boil down to a few basic mistakes that are relatively easy to fix.
Here are seven big security goofs for Kubernetes—all with straightforward fixes.
Default configurations
Many assume that the default cluster configuration is good enough from a security perspective, but this is a mistake. Kubernetes’ default settings are not security-grade, and instead are designed to enable maximum flexibility and agility of developers. Customers must ensure that they properly configure their clusters for proper security.
Multiple admins
Allowing multiple engineers to use highly privileged roles such as CLUSTER_ADMIN for day-to-day operations on a cluster is always a mistake. This role should be used only to manage other roles and users. Having multiple admins with CLUSTER_ADMIN level of access provides hackers with more accounts through which they can enter and abuse your systems with total access to the full cluster.
No access restrictions
Many administrators don’t set restrictions on the type of access developers have to dev/stage/prod clusters. Not every developer requires full access to all the different environments for their role. Realistically, the only access most developers should have is to logs. Allowing developers unrestricted access is bad practice. Similar to having multiple admins, this mistake can be abused by hackers who could use that unrestricted access to move laterally within your systems no matter whose account they gain access to.
Assuming isolation
The assumption that the cluster network is isolated from the rest of the cloud VPC can cause many companies to overlook the need to secure it. The lack of security provides bad actors with an easy entry point.
Failure to secure imported YAMLs
Importing public YAMLs can save you time, and from having to reinvent the wheel, but can introduce misconfigurations into your environment. Companies need to be aware of the security implications of any YAML they introduce into their ecosystems and ensure that any imported configuration issues are mitigated as soon as possible.
Storing secrets in ConfigMaps
Secrets are sensitive data such as a password, a token, or a key. For convenience, or sometimes out of ignorance, developers store these secrets in ConfigMaps, exposing the sensitive data to external hackers who would be able to access the associated resource if they gained access to the ConfigMap.
No regular scans
Many companies have no tools or plans in place to detect issues within their Kubernetes environments. Performing regular scans for misconfigurations and vulnerabilities as early as possible in the software development lifecycle (SDLC) and CI/CD pipeline helps eliminate the possibility of these issues making it to production.
While every company should continuously strive to be among the most secure, you can start by ensuring that you aren’t among the least protected. Hackers don’t want to work too hard; they’re looking for the easiest path to success. Fixing these simple mistakes will improve your Kubernetes security posture, discourage hackers seeking easy targets, and set you on the path toward better Kubernetes security.
Ben Hirschberg is the VP of R&D at ARMO. He is a cybersecurity veteran turned cloud-native security enthusiast and loves writing binary exploits, reverse engineering, and teamwork. When there are no computers around, Ben can be found in the kitchen creating a new dish or reverse-engineering the mind of his latest chess opponent.
—
New Tech Forum provides a venue to explore and discuss emerging enterprise technology in unprecedented depth and breadth. The selection is subjective, based on our pick of the technologies we believe to be important and of greatest interest to InfoWorld readers. InfoWorld does not accept marketing collateral for publication and reserves the right to edit all contributed content. Send all inquiries to newtechforum@infoworld.com.