Red Hat Kubernetes security report finds people are the problem

Puny human brains baffled by K8s complexity, leading to blunder fears

Kubernetes, despite being widely regarded as an important technology by IT leaders, continues to pose problems for those deploying it. And the problem, apparently, is us.

The open source container orchestration software, being used or evaluated by 96 per cent of organizations surveyed [PDF] last year by the Cloud Native Computing Foundation, has a reputation for complexity.

Witness the sarcasm: "Kubernetes is so easy to use that a company devoted solely to troubleshooting issues with it has raised $67 million," quipped Corey Quinn, chief cloud economist at IT consultancy The Duckbill Group, in a Twitter post on Monday referencing investment in a startup called Komodor. And the consequences of the software's complication can be seen in the difficulties reported by those using it.

According to Red Hat's State of Kubernetes security for 2022 report [PDF], the majority of 300 DevOps, engineering, and security professionals survey respondents (55 per cent) said they had to delay the debut of an application in the past 12 months because of security concerns.

Fully 93 per cent of respondents reported at least one security incident in their Kubernetes environment in the past 12 months, with 31 per cent saying this led to revenue or customer loss. The report from IBM's Red Hat lays the blame on Kubernetes' focus on productivity rather than security.

"Kubernetes and containers, while powerful, were designed for developer productivity, not necessarily security," the report says. "Default pod-to-pod network settings, as an example, allow open communication to quickly get a cluster up and running, at the expense of security hardening."

The Layer Eight problem

Such complexity contributes to human error and leads to a lot of fumbled implementations of the software, to some degree.

Red Hat's report says "human error was a major contributing factor in 95 per cent of breaches," citing a World Economic Forum report [PDF] that says "95 per cent of cybersecurity issues can be traced to human error." That report in turn points to a World Economic post that says "studies show that 95 per cent of cybersecurity issues can be traced to human error" – without citing any specific studies.

Whatever the relevant figure, people are involved somewhere along the line and they don't handle complexity all that well. So, says Ajmal Kohgadai, Red Hat product marketing manager, Kubernetes users tend to be more worried about typos than hackers.

"Despite extensive media attention over cyberattacks, the report highlights that it's actually misconfigurations that keep IT professionals up at night," he said in a blog post. "Kubernetes is highly customizable, with various configuration options that can affect an application’s security posture. Consequently, respondents worry the most about exposures due to misconfigurations in their container and Kubernetes environments (46 per cent) – nearly three times the level of concern over attacks (16 per cent)."

Red Hat's answer to this is to automate configuration management as much as possible to reduce the impact of human error.

Toward this end, Red Hat has taken its Advanced Cluster Security (ACS) for Kubernetes, acquired last year via its purchase of StackRox, and released the software as open source under the name of the company that made it.

"The StackRox project aims to help simplify DevSecOps by integrating security capabilities within the development and deployment lifecycle, effectively shifting application security "to the left" in software creation," said Red Hat in its announcement.

The software analyzes container environments for risks, presents alerts, and offers security improvement recommendations.

But before companies can automate Kubernetes, they need people who know what they're doing to write the scripts and configuration files. And finding folks to do that turns out to be the top Kubernetes pain point, cited by 30 per cent survey respondents: "We lack internal talent to use it to its full potential." ®

Other stories you might like

  • Arrogant, subtle, entitled: 'Toxic' open source GitHub discussions examined
    Developer interactions sometimes contain their own kind of poison

    Analysis Toxic discussions on open-source GitHub projects tend to involve entitlement, subtle insults, and arrogance, according to an academic study. That contrasts with the toxic behavior – typically bad language, hate speech, and harassment – found on other corners of the web.

    Whether that seems obvious or not, it's an interesting point to consider because, for one thing, it means technical and non-technical methods to detect and curb toxic behavior on one part of the internet may not therefore work well on GitHub, and if you're involved in communities on the code-hosting giant, you may find this research useful in combating trolls and unacceptable conduct.

    It may also mean systems intended to automatically detect and report toxicity in open-source projects, or at least ones on GitHub, may need to be developed specifically for that task due to their unique nature.

    Continue reading
  • Google battles bots, puts Workspace admins on alert
    No security alert fatigue here

    Google has added API security tools and Workspace (formerly G-Suite) admin alerts about potentially risky configuration changes such as super admin passwords resets.

    The API capabilities – aptly named "Advanced API Security" – are built on top of Apigee, the API management platform that the web giant bought for $625 million six years ago.

    As API data makes up an increasing amount of internet traffic – Cloudflare says more than 50 percent of all of the traffic it processes is API based, and it's growing twice as fast as traditional web traffic – API security becomes more important to enterprises. Malicious actors can use API calls to bypass network security measures and connect directly to backend systems or launch DDoS attacks.

    Continue reading
  • AWS adds bare metal support to EKS Anywhere
    And throws some cold water on the 'K8s works best inside a VM' argument

    Amazon Web Services has made a small but important change to its EKS Anywhere on-prem Kubernetes offering – the option to install it on bare metal servers instead of exclusively inside a VMware vSphere environment.

    "Amazon EKS Anywhere on bare metal enables customers to automate all steps from bare metal hardware provisioning to Kubernetes cluster operations using a bundled open source toolset built on the foundation of Tinkerbell and Cluster API," states the cloud colossus's announcement of the offering.

    The offering is free, but AWS generously offers service subscriptions.

    Continue reading

Biting the hand that feeds IT © 1998–2022