A reverse engineer has discovered what is claimed to be “the first known malware targeting Windows containers to compromise cloud environments,” a sentence to put any system administrator on edge.

Building on work published in December of last year on reverse-engineering Windows containers, security researcher Daniel Prizmant’s latest discovery – made during his day job at Palo Alto Networks’ Unit 42 security arm – looks to punch holes in Kubernetes clusters, and has apparently succeeded in doing so across at least 23 known targets.

“Siloscape is heavily obfuscated malware targeting Kubernetes clusters through Windows containers,” Prizmant wrote of the malware, which he first discovered in the wild in March. “Its main purpose is to open a backdoor into poorly configured Kubernetes clusters in order to run malicious containers.”

A hidden danger
Siloscape does its best to stay hidden, Prizmant discovered, using the Tor Project network and an anonymous .onion domain to connect to a command-and-control server. During his analysis, Prizmant found 313 individual systems connecting to this server – though could verify only 23 active Siloscape victims, suggesting the malware represents only part of a broader attack.

“Compromising an entire cluster is much more severe than compromising an individual container,” Prizmant explained in his report, “as a cluster could run multiple cloud applications whereas an individual container usually runs a single cloud application. For example, the attacker might be able to steal critical information such as usernames and passwords, an organization’s confidential and internal files or even entire databases hosted in the cluster.

“Such an attack could even be leveraged as a ransomware attack by taking the organization’s files hostage. Even worse, with organizations moving to the cloud, many use Kubernetes clusters as their development and testing environments, and a breach of such an environment can lead to devastating software supply chain attacks.”

“This particular malware is extremely impressive,” ESET UK cybersecurity specialist Jake Moore told The Register, “and something even infosec professionals were not expecting. However, this is exactly what we should be doing and expecting the unexpected in all walks of cyber crime. This type of attack can be leveraged into multi-layered attacks causing all levels of disruption and grief to any targeted organisation.”

“While it may seem surprising that we now have malware targeting containers, in reality it shouldn’t come as much of a surprise,” added security specialist Sean Wright. “The way organisations run their services has changed, with more and more organisations deploying their services and applications into containers, most notably Kubernetes. Criminals will adapt as well, and time and time again they have shown if anything they are incredibly resourceful and adaptive when it comes to trying to stay a step ahead.

“Additionally,” said Wright, “since organisations will likely run multiple services within a single Kubernetes cluster, gaining access to this could effectively give attackers an enormous level of access and control. It’s no wonder that attackers have their eyes on this. Combine this with the fact the Kubernetes is still a relatively new technology, many companies likely don’t have the sufficient knowledge to ensure that their instances are configured entirely correctly and most importantly securely.”

Microsoft caught napping
Prizmant had previously reported the ability to break out of Windows container boundaries in July 2020, but to his surprise Microsoft was initially unconcerned. “Microsoft originally didn’t consider this issue a vulnerability, based on the reasoning that Windows Server containers are not a security boundary, and therefore each application that is being run inside a container should be treated as if it is executed directly on the host,” Prizmant recalled.

“A few weeks after that discussion, I reported the issue to Google because Kubernetes is vulnerable to those issues. Google contacted Microsoft, and after some back and forth, it was determined by Microsoft that an escape from a Windows container to the host, when executed without administrator permissions inside the container, will in fact be considered a vulnerability.”

It was shortly after this reclassification that Prizmant discovered Siloscape, which he believes has been actively exploiting zero-day vulnerabilities in containerised applications, and using Windows-specific container escape techniques to gain access to the underlying node and from there the cluster for over a year.

“Users should follow Microsoft’s guidance recommending not to use Windows containers as a security feature,” Prizmant concluded. “Furthermore, administrators should make sure their Kubernetes cluster is securely configured. In particular, a secured Kubernetes cluster won’t be as vulnerable to this specific malware as the nodes’ privileges won’t suffice to create new deployments. In this case, Siloscape will exit.”

Red Hat, Inc., the world’s leading provider of open source solutions, and GitHub, the software collaboration platform home to more than 50 million developers, today announced extended collaboration between the two companies, emphasizing Red Hat OpenShift through GitHub Actions and more. Red Hat is adding Red Hat GitHub Actions to the GitHub Marketplace, bringing GitHub’s DevOps, continuous integration/continuous development (CI/CD) and developer workflow automation tools to Red Hat OpenShift. This further refines the application development capabilities of the world’s leading enterprise Kubernetes platform with GitHub Actions, adding greater freedom to how developers can build and deploy applications on Red Hat OpenShift across the open hybrid cloud.

GitHub has become nearly synonymous with developer tools and serves as the home for many popular software projects, including open source communities like the Linux kernel and Kubernetes. Using GitHub’s built-in powerful, flexible CI/CD solution, GitHub Actions puts automation directly in the developer path, making it possible for nearly any event in a GitHub repository, like a pull-request or issue comment, to trigger workflows that can build and deploy applications across an IT environment and automate nearly any process in the software lifecycle. Organizations often want to bring the familiar, collaborative experience of GitHub to their developers, as well as provide a more secure, common platform for working with open source communities. This makes the availability of tooling like Actions on enterprise Kubernetes platforms a crucial component for the future of IT.

Red Hat OpenShift now supports GitHub Actions, enabling organizations to standardize and scale their use of open, standardized developer toolchain components like Quay, Buildah, or Source-to-Image (s2i). This helps to meet developers where they are and provides greater choice and flexibility to OpenShift customers in how they build and deploy applications. The new GitHub Actions for Red Hat OpenShift, along with existing actions on GitHub Marketplace and action workflows, make it possible to achieve simple as well as complex application workflows on Red Hat’s enterprise Kubernetes platform using an extensive array of standards-based tools.

As part of the collaboration, GitHub has also joined OpenShift Commons, a community that helps drive connections and collaboration across the OpenShift ecosystem. Beyond Actions and GitHub Marketplace, Red Hat and GitHub are also exploring self-hosted GitHub runners for OpenShift. A runner is the combined application and server that hosts a job and carries out the steps for an Action workflow. Self-hosting runners gives IT teams more control and flexibility over the hardware and software included as part of their environment. This means that end users can increase memory size, enable GPUs, or install software that may only be available locally as part of a tailored application development experience.

The addition of GitHub Actions builds on Red Hat OpenShift’s robust developer experience, which includes OpenShift GitOps (based on ArgoCD) and OpenShift Pipelines (based on Tekton). OpenShift is now able to provide a complete solution for DevOps and GitOps practitioners as they seek to build, deploy, and maintain cloud-native applications.

Availability

GitHub Actions on Red Hat OpenShift are available now via GitHub Marketplace.

Supporting Quotes

Joe Fernandes, vice president, Products, Cloud Platforms, Red Hat

“Red Hat OpenShift is more than a Kubernetes platform for deploying cloud-native applications; it’s a powerful, flexible foundation for developers to build the latest and greatest applications. By adding GitHub Actions to our existing set of DevOps and GitOps capabilities and by working with GitHub to further refine and expand the developer experience, we aim to make Red Hat OpenShift the most complete cloud-native development platform available, one built on the open standards of Kubernetes and Linux containers and backed by the vast expertise of Red Hat.”

Jeremy Epling, vice president of Product Management, GitHub

“GitHub is the home for all developers, and we’re excited to expand our collaboration with Red Hat to accelerate software development within the enterprise. Combining Red Hat OpenShift with GitHub Actions will help our customers more securely automate nearly all their cloud-native development and DevOps workflows, providing a unified experience across the hybrid cloud that is exceptionally friendly to developers, security and operations teams. We’re looking forward to working more closely with Red Hat, and helping our customers deliver better and faster with open source software and standards.”

Microsoft launched a more complete Kubernetes tool to manage clusters on its Azure infrastructure-as-a-service (IaaS) that its open source team recommends as a replacement for the existing AKS Engine offering. The Cluster API Provider for Azure (CAPZ) also takes a step back from what has been a more abstracted view for managing container clusters on public cloud infrastructure.

Craig Peters, principal program manager for Azure container compute at Microsoft, explained in an email to SDxCentral that CAPZ is a tool that can be used specifically on and is complementary to infrastructure like Azure Kubernetes Service (AKS), Azure, and Azure Arc.

It’s built on the open source Cluster API (CAPI) Kubernetes sub-project, which is designed to provide declarative APIs and tooling to simplify provisioning, upgrading, and operating of multiple Kubernetes clusters. CAPZ takes that base and works through the Azure Resource Manager (ARM) to provide greater control for self-managed Kubernetes clusters on Azure and Azure-managed Kubernetes clusters.

“CAPZ enables users to use CAPI to create and manage either self-managed clusters where the user owns the control plane, uptime, and maintenance entirely themselves,” Peters wrote. He added that CAPZ is a tool that can be used specifically on Azure infrastructure through ARM to manage Kubernetes clusters through the Cluster API.

Basically, CAPZ provides for a greater level of management over Kubernetes clusters that are running in one of these managed environments. This allows it to bridge the gap between a user relying exclusively on their managed host for that control or attempting to manage Kubernetes on their own.

In an accompanying blog post, Peters explained that while AKS remains a “mature, scalable, secure” and fully Microsoft-based platform, it does not have the depth of control that some developers require.

“Some need functionality that is not available in AKS yet or might never be because they require user access to the control plane,” he wrote, noting that this need could be tied to regulatory or compliance issues, or even just a developer needing more control over Kubernetes features.

CAPZ Caps AKS Engine
That greater flexibility is also behind Microsoft’s move toward recommending CAPZ over its legacy AKS Engine product. AKS Engine is designed as a templating tool for turning cluster models into ARM templates to manage Kubernetes clusters but lacks flexibility as it can only create one cluster at a time, which limits scalability, and only on Azure.

“AKS Engine has been the workhorse for teams who need to operate their own clusters on Azure,” Peters explained. “The ARM template workflow is natural for some Azure-focused teams but doesn’t provide the power and flexibility of CAPI.”

However, Peters’ in the blog post noted that the “design falls short of empowering ongoing operational needs such as scaling, in-place upgrading, and extension management. And it isn’t useful for users who are focused on multi-cloud scenarios like managing fleets of Kubernetes clusters across cloud infrastructures that do not support ARM.”

As such, his team is suggesting that AKS Engine users look at CAPZ as it provides stronger support for managing the cluster lifecycle and that it will be the focus for all new investments from that team.

Mirantis this week rolled out Mirantis OpenStack for Kubernetes, an instance of the open source cloud management framework in which all the components have been encapsulated in containers.

Shaun O’Meara, global field CTO at Mirantis, says that approach makes it possible to then employ Kubernetes to orchestrate those containers.

Mirantis OpenStack for Kubernetes is the first in a planned series of enhancements to the Mirantis Cloud Native Platform, a family of offerings based on Kubernetes that includes Mirantis Container Cloud, the container platform formerly known as Docker Enterprise that Mirantis acquired last year.

O’Meara says the goal is to make it easier to deploy, manage and update a widely employed cloud management framework that continues to be advanced under the auspices of the Open Infrastructure Foundation, formerly known as The OpenStack Foundation.

That approach also makes it possible to deploy OpenStack on either a virtual machine or on a bare-metal server, notes O’Meara. Even the kernel-based virtual machine (KVM) foundation on which OpenStack is most frequently deployed has been encapsulated in a container, he says.

Bare-metal instances of Kubernetes are gaining traction among financial service firms, organizations that are building artificial intelligence (AI) applications based on machine learning algorithms and telecommunications carriers—all of which trying to minimize the overhead a virtual machine adds to an IT environment, notes O’Meara.

OpenStack is most widely employed by telecommunications carriers and other IT service providers as an open source alternative to a commercial stack of virtual machine software from VMware. That approach enables organizations to deploy a cloud framework at scale without incurring massive software licensing costs.

The OpenStack framework has seen less adoption among enterprise IT organizations, but O’Meara notes that since the transition to cloud-native computing began, adoption of OpenStack has increased as organizations look to deploy containerized applications at scale. Mirantis OpenStack for Kubernetes will enable both service providers and enterprise IT organizations to expand their reliance on OpenStack using the same Kubernetes orchestration engine they already employ to manage containers in what are now highly distributed computing environments, he says.

That approach ultimately serves to reduce the total cost of managing IT environments that need to be able to run both cloud-native applications and legacy monolithic applications, he adds.

Longer-term, the convergence of Kubernetes and OpenStack should reduce the level of tension that surrounds both platforms. As Kubernetes continues to evolve, there are those that advocate the platform will one day replace OpenStack with a set of cloud-native extensions. The Mirantis approach effectively turns all the components that make up OpenStack today into a set of containers that run natively on Kubernetes. Previously, organizations could deploy OpenStack on Kubernetes, but each component was not a set of containers that could be individually orchestrated.

Of course, Kubernetes today is more commonly deployed on OpenStack and VMware because it provides a method for provisioning a complex platform using a familiar set of IT management tools. However, as cloud-native computing environments continue to expand, the relationship between the components that make us a management framework and Kubernetes are clearly still evolving.

The team behind service mesh Istio has released version 1.8 of its project. The last major update of the year showcases further advances of the Istio User Experience working group and improves on some security aspects.

For example, the mesh has stopped reading certificates directly from Kubernetes and now sends them from Istiod to gateways instead. The approach supposedly makes the often publicly exposed gateways less of a risk factor while also upping performance.

Version 1.8 also looks to allow users to connect to certificate authorities besides the one that Istio ships with. This is done using the Kubernetes CSR API, while Istiod serves as a registration authority to authenticate and authorise workloads. The experimental feature allows any third party tool working with the Kubernetes CSR API to create a signed certificate for the appropriate backend CA, making it easier to integrate into a more complex workflow.

In terms of usability, the Istio team has worked a bit to make meshes easier to debug, adding a bug report with debug information and the cluster state to istioctl. It also adjusted the command line utility’s analyze tool to show the line number for cases in which objects don’t validate properly and made the dashboard more user friendly by allowing something like istioctl dashboard envoy deployment/productpage to refer to pods indirectly.

Easy installation and good documentation still play a major role when it comes to convincing organisations to buy into an open source project. Istio has done a lot in this regard lately, so version 1.8 includes a new guide for installing multiple cluster-spanning meshes and help when using virtual machine mesh endpoints. Those can now be installed via istioctl, though there are also auto registration and a smart DNS proxying feature available to simplify things further.

Smart proxying promises to “resolve mesh services from your VMs, without having to insecurely point them at your cluster DNS server”, though the reduction of cluster DNS traffic and the number of look-ups to resolve a service’s IP address are nice side effects. Auto registration also pretty much does what it says on the tin, leading to Istio automatically creating WorkloadEntry objects for a VM agent when it joins a mesh.

Istio 1.8 also is the first version to sport experimental support for using Helm 3. The latter complements istioctl install and the Istio operator for installation purposes and is meant to get more teams on board who have built their software deployment workflow on Helm.

However, the new addition seemingly makes things more complicated for those new to the container game as it can be hard to figure out which approach is best for a given scenario. For that reason the Istio website now sports a FAQ section pointing out pros and cons of each method.
Users whose setup still depends on the Mixer component should note that it was removed with the latest Istio release. To make sure extensions keep working, they will therefore either have to be migrated to web assembly or the Envoy authorisation and access log services will have to be enabled, so that Mixer 1.7 can still be used. Help with that can be found in the Istio wiki.

Kubernetes is quickly consolidating its place as the leading container orchestration platform for cloud-native applications, with adoption at 59% among enterprise IT professionals as of March. But while Kubernetes delivers agility, flexibility and scalability for DevOps teams, it also creates complexity that can be an enigma for SecOps teams—especially when something goes wrong.

When it comes to detecting threats and tracking down breaches in Kubernetes, security teams’ key asset is the Kubernetes API server audit log. The audit log captures every successful or unsuccessful API server call, whether by human users, automation pipelines, controllers, operators, system components and, in general, API server operations performed by principals identified as service accounts. In other words, the audit log is the single source of truth for what’s happening inside a Kubernetes infrastructure.

But just because the audit log tracks all the activity in your Kubernetes environment doesn’t make it easy to find what you’re looking for. The larger your infrastructure, the more events there will be to parse through. The Kubernetes audit log is also extremely verbose, capturing a number of identifying attributes for each action, such as detailed information about what resource was accessed, who accessed it or what IP address the request came from. When the Kubernetes infrastructure at hand involves multiple clusters, which is the most common use pattern, it becomes a daunting task to place effective security monitoring controls across all clusters and manual security audit log monitoring becomes extremely impractical.

One simple approach to automate Kubernetes Audit log monitoring, which is quite useful for compliance purposes, is through the use of simple static policies that trigger alerts when a violation occurs. For example, an alert could be triggered if a human user accesses a workload that processes sensitive data. This simplified approach is useful when you have a precise notion, as in cases of regulatory compliance of what use patterns are allowed. However, in real-life deployments, adversaries never limit themselves to what is allowed.

Another approach is threshold-based security monitoring, which captures when API events, or combinations of events, rise above a certain threshold. However, this tactic can be easily bypassed by an adversary simply by controlling the rate of compromise attempts, spreading the attack out over time to avoid crossing the threshold.

Threshold-based based monitoring is also prone to false positives that can really wear out security and teams and create alert fatigue. For example, periodic batch processing workloads, which create a frenzy of API calls, would break through pre-configured thresholds but aren’t actually a threat. To separate threats from routine deployment events, you need to understand the context, something threshold-based monitoring alone cannot provide.

With significant, high-maintenance efforts, and potentially high rates of false alerts, threshold-based monitoring can help security or operations teams to catch known threats and vulnerabilities, but it won’t catch unknown threats or vulnerabilities. Again, to identify a threat, you need to be able to understand the context of any anomalous behavior: who is making the API calls, from where and what resources are they accessing. You also need to observe this data over time to establish what normal behavior looks like so you can differentiate it from anomalous behavior.

As a powerful, elastic and flexible cloud-native application infrastructure that drives many automatic processes, Kubernetes is inherently complex. To detect a security threat in Kubernetes, you need an adaptive security monitoring solution powered by machine learning. Through time-based observation of the various actors within a Kubernetes cluster that leverage the API server audit log, machine learning can learn and detect anomalous patterns in actor activity that simple tools will miss.

Learning the behavior of your clusters is no trivial task. Profiles for different users, components and automated services need to be built over time, and with so many moving parts, this is impractical to do manually. At the same time, new vulnerabilities are constantly coming to light, and there will always be vulnerabilities that are waiting to be uncovered. You can set alerts for vulnerabilities you know, but to catch unknown threats you need a strong baseline of activity in your cluster to monitor against, something that the right machine learning algorithms can readily capture and adapt to over time.

While machine learning is a broad topic, it is quite clear that the traditional approach of supervised or unsupervised offline model creations would not yield satisfying detection results, simply because different environments are accessed and behave differently. There has to be a component that learns and adapts to the specific Kubernetes environment being monitored.

Here are two security use cases that machine learning can reveal through the analysis of the Kubernetes audit log stream:

Stolen Service Account Tokens and User Credentials

Machine learning-based audit log monitoring tools can alert security teams of suspected credential theft. For example, if the same cluster credentials are reused from multiple different geographic or network locations within a short period of time, it can be flagged as an anomalous behavior and, if combined with additional abnormalities, could indicate stolen credentials.

By tracking and learning the geographical attributes and the access patterns of individual users or principals, machine learning can detect this anomalous behavior and flag it for security teams. In response, the security team can take actions to reduce or eliminate the blast radius—such as limiting access to the API server from the specific suspected IP address or modifying the Kubernetes role-based access control (RBAC) policy to reduce access privileges for the specific account.

Misconfigured Kubernetes RBAC

In addition to detecting threat actors that attempt to pivot within the Kubernetes cluster, machine learning can also leverage the audit log to detect attempted exploits of known or unknown vulnerabilities if the RBAC permissions are misconfigured or over-permissive. On the flip side, once RBAC policies are properly configured, reducing RBAC privileges to the required minimum, machine learning can alert when unauthorized users make unsuccessful API calls to access sensitive resources, indicating a failed exploit attempt.

Ultimately, the audit log is an incredibly rich source of information on activity within your Kubernetes environment and a valuable tool for both detecting threats and vulnerabilities and forensically tracing breaches. Although the complexity prohibits manual monitoring, machine learning can give security teams real-time observability into security incidents within their Kubernetes environments and enable informed investigations and audits that get to the root of problems more quickly.

Western Digital’s composable OpenFlex flash storage system now supports Kubernetes storage, courtesy of Linbit’s LINSTOR software.

OpenFlex is a physical chassis, containing SSDs or disk drives, which is addressed as an NVMe target device. It’s basically an NVMe-oF JBOD (Just a bunch of drives) and needs additional software to link it to containerised environments.

Manfred Berger, WD’s senior manager for business development, platforms, said in a statement: “With Linbit’s LINSTOR software added to our OpenFlex offering, the software-defined-storage solution combines the advantages of SDS systems, Linux OS features and composable hardware so that organisations have the confidence they need in their Kubernetes environments.”

Philipp Reisner, Linbit CEO, said: “With the open-source LINSTOR we bridge the gap between the workload orchestrator (Kubernetes) and the efficient OpenFlex storage devices from Western Digital. In combination delivering high-performance block storage at a very attractive price point.”

LINSTOR is configuration management system for storage on Linux systems. The software use the Linux LVM tool to manage logical volumes and/or ZFS ZVOLs on a cluster of nodes. Linbit has developed a Distributed Replicated Block Device (DRBD) storage construct for Linux and LINSTOR uses this to provide block storage devices to users and applications.

LINSTOR sees WD’s OpenFlex Composable Infrastructure as an NVMe-accessed storage pool from which it can allocate space to DRBD. OpenFlex has a REST Open Composable API which is used by LINSTOR to do this.

That’s the downstream aspect sorted. On the upstream side there is a LINSTOR Operator to deliver DRBD capacity to Kubernetes. It installs DRBD in Kubernetes environments, thus linking OpenFlex and Kubernetes, and manages Kubernetes satellite and controller pods.

Building a tool for Kubernetes developers means solving a bunch of problems (e.g., multiple clusters, kubeconfigs, secrets, kubectl functionality, how to represent the hierarchy of abstractions inside a cluster, etc.) and creating a user experience that promotes speed. A good dashboard lets you select from among multiple clusters and:

See the states of everything and work with whatever you’re permissioned to access (this translates into zero need for IT operators to centrally administer dashboard-specific permissions).
Drill into abstractions—see what’s running and what’s dependent on what.
Identify what’s relevant to your work right now—i.e., let you constrain context.
Accelerate your work: navigate around local directories, control local applications (e.g., Git, VSCode, etc.) from the command line, view/edit/reapply abstractions, grab container logs, log into container shells, etc.
Browse and apply Helm charts, etc.
And maybe also maintain several contextualized work-sessions in parallel (different projects, different clusters, etc.), so you never need to spend cycles finding your place.
What’s interesting is that solving these problems well means you’ve already solved some important additional problems. You know how to create and maintain contexts in which work can happen efficiently. And in so doing, you’ve mastered important aspects of the integration puzzle that turns a ‘context’ into a ‘workflow.’

Specifically, you’ve mastered the terminal, which is the interface most devs use to coordinate local (and remote) applications, CLIs, and the artifacts they create and consume. You’ve mastered the Kubernetes API, and through that, the substrate of tools (e.g., Helm) used to configure, deploy and lifecycle-manage applications, components and services, including the integrated, non-Kubernetes-native solutions on which you depend to support your bespoke applications (such as [third-party] Ingress or Message Queue or Metrics or Database, etc.).

This given, a strong Kubernetes dashboard can, in principle, become a full-fledged Kubernetes IDE by creating some relatively simple integration ‘glue’: code that lets contributors build ‘extensions’ in a simple, secure, standardized way. A way that lets extensions automate what you, yourself could do manually (assuming you knew how).

For a specific kind of app, say an ingress controller, this might involve:

Inheriting your permissions (or, in some cases, organizing and remembering separate permissions for certain services).
Discovering relevant applications/services (i.e., ingress controller components, sidecars, manager workloads, operators, etc.) in the cluster you’re now looking at.
Dynamically representing the state of those ingress components within the ‘dashboard’ webUI.
Extending the webUI and/or dashboard configuration dialog(s) with bespoke sections that simplify ingress configuration.
Plus other features, such as automatically extracting parts of, or the whole hierarchy of ingress objects so you can store these files locally and place them in version control.
It’s easy to imagine extending this fundamentally-simple (in principle; obviously, it can be tricky to implement in practice) model to let extensions drive all sorts of components and provide a wide range of valuable services to developers. Assuming your dashboard already knows how to import and apply Helm charts; it should be simple to create the extension equivalent of an IaaS database-as-a-service (DBaaS) framework, where the extension maintains a perpetually-updated list of trusted sources for 15 major databases and provides basic configuration options and one-click installation for each type, bookmarking access to product-specific configuration tools for further work.

Such an arrangement around an extensible dashboard could benefit the entire community, including:

Developers: Who are free to install (or build) open source extensions for their favorite tools, thus creating flexible, highly-customizable, and efficient working environments within the dashboard. (Working environments that can, in principle, be packaged and shared among, for example, developers collaborating on a given project).

Operators: Who are also free to create and share collections of extensions, so able to ‘soft-standardize’ working environments without making developers feel as though they’re being dictated to. Operators can, meanwhile, closely-manage RBAC permissions on any cluster, ensuring that dashboard+extension users are never able to go ‘out of bounds.’

CNCF ecosystem participants: Building extensions to manage components under inherited RBAC permissions from within a dashboard environment that supports terminal and Kubernetes API/kubectl sessions, and that also provides sophisticated, widget-rich weblike functionality for visualization and interaction, is easier than maintaining many integrations to specific development tools. It’s also potentially far more useful to developers, who can adopt subsystem/tool-specific extensions as part of their evolving workflows—improving quality of life as opposed to learning yet another UI, CLI, or REST API. Making tools and components more consumable by developers (and operators) can be an important selling proposition in an ecosystem dominated by YAML and crude interaction principles (e.g., edit YAML, change YAML, reapply YAML, rinse, repeat).

The critical factor, of course, is whether such an extensible dashboard can reach sufficient critical mass to become the preferred way of packaging functionality and accelerating development—completing its evolution into an ‘IDE,’ and perhaps even becoming a sort of framework.

Here, it feels to me as though what’s most important is that the dashboard sits where a certain subset of Kubernetes coders and operators do most of their work, which is in the tight, iterative loop between the desktop and the cluster. This is quite different from classic IDEs, built around code editors. Obviously, the latter are still vitally important when work is focused on new application coding or on maintaining mature application code, particularly where back-end processes are fully automated with CI/CD.

But as most Kubernetes-centric developers are coming to realize, there tend to be big gaps (and latencies) in this model that only a dashboard-centric, context-aware, extensible IDE is ‘fast enough’ to fill. Once the containers are built, people need tools purpose-designed for iteratively tweaking the abstractions that put those containers to work. Once those YAML files are tested and made part of application lifecycle and/or infra-as-code repositories, and when the CI/CD has been extended to apply them automatically (in our ideal universe), there’s now forensics, break/fix and other new tasks that need to happen on that bleeding edge of dev-to-cluster iteration.

StackRox today unveiled an open source static analysis tool dubbed Kubelinter that analyzes YAML files and Helm Charts to identify misconfigurations in Kubernetes deployments prior to deployment.

Viswa Venugopal, staff software engineer at StackRox, says given the prevalence of misconfigured Kubernetes clusters it’s apparent there is a need for a security tool that IT teams can employ before a Kubernetes cluster is deployed. Written on the Go programming language, Kubelintr accomplishes that goal in a single binary file that IT teams can run in a command line, he says.

Longer term, StackRox plans to add auto-remediation capabilities to Kubelinter that IT teams can employ as they best see fit depending on the impact those changes might have on their applications. Many existing clusters are running older versions of Kubernetes that were not designed to support security capabilities that have been included in the more recent versions, notes Venugopal.

Configuration issues among early adopter of Kubernetes clusters have become an issue because of the complexity of the platform. Most developers who have spun up Kubernetes clusters are primarily focused on simply getting the platform to run. As such, they often overlook the fact that the default setting for Kubernetes are fundamentally insecure. Security settings are not turned on by default because it adds additional complexity to a platform many IT teams are already struggling to master, he says.

KubeLinter provides an automated means to carry out configuration checks as part of a continuous integration (CI) workflow that makes it easier to track how changes are proposed and made to YAML files and Helm charts, he adds.

A recent survey of 400 IT and security professionals conducted by StackRox finds human error to be the main cause of most Kubernetes security incidents, with misconfigurations contributing to roughly 67% of the incidents reported by survey respondents. A total of 90% of respondents report they experienced a security incident in their container and Kubernetes environments over the last 12 months, with 44% noting they delayed moving an application into production because of security concerns.

Despite misconfiguration issues, the rate at which Kubernetes clusters are being deployed continues to accelerate as organizations look to deploy microservices-based applications that are both more flexible and resilient. Many of those applications are driving digital business transformation initiatives that require applications that can also be more easily updated as business conditions change.

The challenge organizations face is cyber criminals are also tracking this transition. Tools for scanning for misconfigured Kubernetes clusters are readily available. The paradox is that some of the most strategic applications any organization has deployed in years are running on Kubernetes clusters that are often misconfigured.

It may be a while before best DevSecOps practices evolve to point where misconfigurations of Kubernetes clusters become less of an issue. However, as more tools to address the issue become available, it may now only be a matter of time before most IT teams are configuring Kubernetes clusters right every time they are deployed.

Aqua Security today unveiled a Kubernetes Security Posture Management (KSPM) offering that provides IT teams with a set of policies and controls to automate configuration and compliance of Kubernetes clusters.

In addition, Aqua Security has added a Kubernetes Runtime Protection module that provides an option for using Kubernetes Admission Controllers to deploy security controls as a set of sidecar containers directly on to a Kubernetes pod.

KSPM comes with more than 20 predefined rules available out of the box as well as support for Open Policy Agent (OPA) Rego rules that IT teams can use to build custom rules. These policies work in conjunction with existing Image Assurance Policies developed by Aqua Security to control which containers run in a cluster based on their contents and configuration as well as pod configuration.

In addition, a Kubernetes roles and subjects assessment capability tracks user and service account privileges to identify risks and make remediation suggestions.

The company also updated its Cloud Security Posture Management (CSPM) offering for containers and virtual machines to include a customizable dashboard, support for the Amazon Web Services (AWS) Bottlerocket operating system, auto-remediation capabilities on the Microsoft Azure cloud, additional compliance reporting and the ability to scan NFS mounts.

Rani Osnat, vice president of strategy and product marketing for Aqua Security, says as Kubernetes becomes more widely deployed in production environments the number of attacks aimed at misconfigured Kubernetes clusters will increase steadily. The issue is that given the complexity of Kubernetes, it’s relatively easy to make a mistake, he notes. Many IT teams are also worried about breaking applications when they add additional security controls after a Kubernetes cluster is up and running.

In fact, most Kubernetes clusters are deployed by developers who have limited security expertise. The roles and subjects assessment capability enabled by Aqua Security should make it easier for developers to securely deploy Kubernetes clusters by surfacing setting recommendations based on risk versus simply presenting developers with a set of configuration issues that lack any context, adds Osnat.

No developer deliberately sets off to deploy a misconfigured Kubernetes cluster. Developers in the interest of speed are using tools such as Terraform to automate the deployment of Kubernetes clusters, many of which are inadvertently misconfigured. Cybersecurity teams don’t always have the time or expertise required to vet those deployments.

Those issues, however, don’t appear to be slowing down the rate at which Kubernetes clusters are being deployed, as organizations rush to build and deploy cloud-native applications. The need to build more flexible and resilient applications is trumping security concerns.

As organizations eventually embrace best DevSecOps practices, many basic security issues should be addressed as part of the workflow of building and deploying cloud-native applications. As is always the case with any emerging IT platform, security is once again playing catchup, notes Osnat.

NetApp today at its online NetApp Insights 2020 conference announced it has added a storageless computing service that extends an existing Spot Ocean serverless computing framework for containers to make storage resources available on-demand in Kubernetes environments.

Ronen Schwartz, senior vice president and general manager for cloud volumes at NetApp, said as Spot Storage by NetApp continues to evolve, IT organizations will be able to leverage a storageless computing framework across hybrid cloud computing environments without having to administer storage infrastructure.

Spot Ocean already provides real-time analysis of pod and task requirements to predict compute resource requirements. It then makes spot, reserved or on-demand instances of compute resources available based on the cost-sensitivity of the IT budget when needed. That capability is now being extended to also apply to storage infrastructure using Kubernetes clusters that enable Spot Storage NetApp to programmatically orchestrate storage resources.

NetApp today also launched NetApp Cloud Manager, which makes it possible to manage data synchronization, data backup, data tiering, file caching and compliance across storage volumes residing in public clouds and on-premises IT environments. At the same time, NetApp unfurled a fully managed, cloud-based NetApp Virtual Desktop Management Service (VDMS) intended to make it easier for organizations to enable employees to work from home.

Serverless computing frameworks have been gaining traction in the cloud because they enable developers to dynamically invoke additional infrastructure resources on-demand. NetApp is now extending that capability to storage resources accessed by microservices-based applications deployed on Kubernetes clusters to create storageless environments. Most of those clusters today are running on cloud services but it’s only a matter of time before Kubernetes clusters are more widely deployed in on-premises IT environments.

In the meantime, the number of stateful applications being deployed in Kubernetes environments inside and out of cloud platforms is just now starting to increase. However, many of the IT teams deploying these applications lack dedicated storage expertise. Spot Storage by NetApp eliminates the need to have a dedicated administrator to manage storage environments that need to dynamically scale both up and out as required.

Storage administrators used to take great pride in their ability to optimize access to shared infrastructure resources across multiple applications. However, as the amount of data now being accessed by potentially thousands of microservices grows, it’s not possible for one storage administrator to keep pace. It’s now less expensive to make storage resources available to any application based on immediate requirements without having to worry about the cost of overprovisioning storage.

Storage costs will continue to rise as the amount of data organizations increases. However, the overall IT environment will become more flexible because no one will have to wait on a storage administrator to acquire, deploy and configure additional storage arrays.

As infrastructure becomes managed as code, many of the manual tasks previously associated with managing storage increasingly are becoming automated. It may be a while before all those tasks are completely automated, but within a modern IT environment running Kubernetes, many of those manual IT tasks are already antiquated. Storage is just the latest example.

The widespread adoption of the Kubernetes standard for container orchestration has redefined how organizations manage computing deployments at the edge. In turn, more innovative use cases have emerged for lightweight Kubernetes distributions like K3s, designed for small footprint workloads.

These Kubernetes deployments can range in size from 500 to 600 single-node clusters to 15,000 to 20,000 clusters, with an average size of 1,700 clusters. As an example, an oil and gas support services company, and Rancher Labs customer, intends to support a mobile fleet of more than 600 vans that act as mini data centers. Traveling to remote oil wells, these vans use Kubernetes to conduct sensor analysis, measuring everything from drill efficiency to flagging potential gas hot spots.

Another organization has plans to use Kubernetes across its 100 factories. Single-node clusters each manage purpose-built, programmable applications that run robotics and machine components in production lines.

Single-Node Kubernetes Clusters, Multiple Issues
But the proliferation of single-node clusters creates three primary infrastructure management challenges: security, heterogeneous architectures and limited connectivity. To manage clusters on a massive scale, organizations need to overcome these challenges.

Securing the Edge
Security is a fundamental concern as enterprises push compute and storage outside the data center into hostile environments where there are no physical security barriers.

For example, thousands of people might visit a retail environment every day. There is nothing stopping someone from reaching over the counter, unplugging a small footprint device and walking away with it.

Security starts at day zero when the machine is built using a bill of materials, shipped to a location and installed. It must remain secure in transit and not be tampered with before being switched on. Once activated, the machine must verify that no rogue software has been installed. Only then can it securely register with its management system.

The day-two problem centers on the continuous secure management of these devices. Imagine the logistics if an organization has 1,700 of these clusters deployed across a continent, many in remote locations with limited or intermittent connectivity. It is simply not practical to send people to manage and verify the security of each device.

There are several open source projects that help in this regard.

The Intel Secure Device Onboard (SDO) solution provides a similar plug-and-play experience to that of connecting a USB device to a laptop. With SDO, an edge device can be securely and automatically onboarded in a zero-touch manner into the cloud environment in less than a minute.

Another open source project is Keylime, MIT’s remote attestation based on the Trusted Platform Module (TPM). This creates a Hardware Root of Trust from the TPM chip built into a device all the way through to the data center. Using the TPM cryptographic hash, Keylime conducts trusted verification of the device to ensure it has not been tampered with on a hardware or software level.

Managing Heterogeneous Architecture
An organization with a large number of edge devices might use a mix of ARM and Intel-based architectures, making multi-operating system support essential. In these cases, enterprises need to support continuous integration pipelines for each device type. Some use cases also require graphics processing units (GPUs) to support the workloads.

For instance, a fast-food chain might use GPUs for visual analysis to count the number of cars at a drive-thru. These GPUs can also be used to process languages such as the conversation between the customer at the drive-thru and the person taking the order inside the restaurant. Using GPU-backed conversational AI, interactions can then be analyzed on a national level to determine whether employees understand customers and identify areas where training can enhance the experience.

To optimize capital expense (CapEx), organizations must first define the use case for the Kubernetes clusters. Working backward from workload requirements, the appropriate hardware bill of materials is specified to support that use case. In the example of the fast-food restaurant, GPU support is critical. At scale, these Kubernetes clusters (many of which are single-node clusters) can then be engineered in a purpose-driven model so that overprovisioned hardware doesn’t go to waste.

Kubernetes must therefore be architecture-agnostic. This is critical to meet both the business demands for the customer as well as the application use case, whatever that might be.

Connecting the Edge
Kubernetes deployments also face challenges in limited or intermittent connectivity environments. This means container sizes cannot be so large as to clog the pipeline and limit how quickly updates can be delivered to the edge.

The proliferation of Kubernetes typically sees most clusters purpose-built with small hardware profiles without much memory or storage space. For example, a machine might only have 2GB of RAM, one reserved for infrastructure and the remaining memory footprint to run workloads. Development teams must therefore build applications that target small file sizes. This is also important when considering how long it might take for an update to reach a container in limited connectivity conditions. Containers must, therefore, be kept as small as possible.

This is where the GitOps operating model comes into play. It provides a set of best practices to join deployment, management and monitoring for containerized clusters and applications. Within that, Kubernetes can leverage a pull model that sees the edge “phoning home” for updates when there is connectivity in place. At scale, having tens of thousands of clusters do this is significantly more effective than trying to push down updates when there is no reliable connectivity.

A Standardized Approach for Kubernetes
These edge use cases scratch the surface of the potential for CNCF (Cloud Native Computing Foundation)-certified Kubernetes distributions to enable the internet of things.

The standardized Kubernetes API (application programming interface) is perhaps the most powerful aspect that comes from Kubernetes. This means that every Kubernetes cluster can link to any cloud environment, regardless of the service provider. With one API guiding everything, the cloud ecosystem now has a standardized way of managing all its infrastructure.

The notion of a hybrid cloud is behind us. Using a single API that can point and connect to wherever the cloud is for an edge device creates an environment where Kubernetes can be everywhere and run everything.

The addition of VMware’s Tanzu application modernisation suite to VMware Cloud on AWS would see more organisations adopting cloud-native apps and provide flexibility, according to CMD Solutions boss Andre Morgan.

Sydney-based CMD is an AWS partner and cloud consultancy that also specialises in application modernisation through containers like Kubernetes. The company is also an accredited VMware Cloud on AWS partner.

Following the recently concluded VMworld 2020, CMD was receptive to the announcement around Tanzu, VMware’s suite of software and services that allow customers to build, run and manage a kubernetes environment from a single control point.

“We’ve been really excited about the VMware Cloud on AWS offering and everything around it so we can service more clients using a combination of VMware and AWS,” Morgan told CRN.

“A lot of our clients are trying to modernise their fleets, and they’re using Kubernetes as part of that strategy, so for me the announcements around Tanzu were the most exciting announcement from VMworld.

VMware recently announced at VMworld 2020 it expanded Tanzu support across VMware Cloud on AWS, Azure VMware Solutions and Oracle Cloud VMware Solution, as well as a partnership with GitLab.

VMware said the updates provide customers with “fast and more secure ways” to extend workloads to the cloud, while also offering customers a ubiquitous platform for running applications on the infrastructure of their choice.

“Application modernisation is hard work for everyone that’s doing it and it takes a lot of effort, and some clients are going full steam ahead and doing it in a cloud-native way,” Morgan added.

“However not all of them want to embrace it heavily and it makes more sense for them to continue with their familiar skills and experience around the VMware suite of products around VSphere, and actually leverage that but still get the benefits of modernising.”

“And that’s why I’m really excited about the addition of Tanzu to VMware Cloud to AWS, because if that wasn’t around, then many wouldn’t make the jump to could-native.”

It may seem as if these days everybody is using Kubernetes. There’s a lot of hype. But the truth is, most companies are still using virtual machines and on-premises data centers, and that’s quite fine. Before you go and adopt Kubernetes, I want to share with you some misconceptions about Kubernetes and help you understand those problems won’t be magically solved by adopting it.

Will Kubernetes Reduce Your Costs?
One of the most popular reasons to adopt Kubernetes is to reduce costs. After all, if you can magically reschedule all your workloads in a much more efficient way, won’t your cloud bill suddenly go down?

First things first—you have to understand microservices are very inefficient by nature. Every time you hand off work across the (virtual) network, you pay for serialization and deserialization costs, memory copies (which traditionally both the kernel and the runtime have been working hard to avoid) and potentially various middlewares such as service-meshes and security software.

This pattern does not offer efficiency—it offers scalability, which is quite a different beast. And it’s obviously only relevant once you pass a certain scale. If you can run much of your workload on as many cores as fit inside a single computer, you are not at that scale yet!

The truth is that Kubernetes is quite good at packing lots and lots of light container workloads into fewer nodes. But, if your workload is containerized by nature, you are probably already using Kubernetes (or Docker Swarm, or Mesos, for that matter). On the other hand, if your workload is not heavily containerized, you have little to gain by moving to Kubernetes.

Will Kubernetes Be Transparent for Your Developers?
If your domain lies in site reliability engineering or DevOps, you might be thinking that adopting Kubernetes is in your realm and has little or nothing to do with your software engineering team. The truth is quite different. While running workloads on Kubernetes won’t require every single member of the team to understand the intricacies of Kubernetes ingresses, they are definitely going to have to know their way around.

Whether it’s spinning up a development environment (local or in the cloud), running basic `kubectl` commands on it or just being able to have a bird’s eye view of the architecture, your developers are going to be a part of this journey. You better have them onboard.

Will Kubernetes Help Break Down Your Monolith?
Many companies are struggling with an out-of-date monolith (often written in Java or C#) that they are looking to revolutionize. You might be one of them. The promise of migrating to a modern cloud-native technology seems enticing.

And yet, you have to realize most migration processes tend to be more of the “lift and shift” kind. Meaning, you are gonna be stuck with the same old monolith, except it’s gonna be running inside a much more complex and hard-to-access environment, instead of a plain old VM.

Breaking down a monolith into microservices should start with the Strangler methodology and you shouldn’t worry too much about the orchestration method when getting started. As things start to take shape, Kubernetes is definitely an awesome candidate.

Will Kubernetes Allow You to Move Faster?
So many tech-savvy companies out there are using Kubernetes. And they are definitely moving fast. Won’t we be moving faster as well by adopting Kubernetes?

Unfortunately, the answer to that question is almost certainly “no.” The most common reasons I have encountered that prevent teams from moving fast are:

Slow or inadequate tests.
Lack of automated build and deployment capabilities.
Poor understandability of the application.
Each of those problems is separate, and none of them are directly related to Kubernetes. Go ahead and invest in CI, CD and understandability. Containerization may definitely help. Kubernetes might come later, or it might not. But there are almost certainly higher-priority concerns to address if increasing velocity is your goal.

Is Kubernetes Better Than What You Currently Have?
If you have read this far, you are probably not satisfied with whatever orchestration solution you already have (or you just might be reading through before you roast me in the comments). And while Kubernetes is definitely awesome, it’s a complex system with many shortcomings. To be honest, it’s quite likely to cause as many problems as it’s going to solve for you.

If you are using a remote configuration tool such as Chef, Puppet or Ansible, that just might be what’s right for you. I would definitely recommend considering containers for most of those workloads, but that can still be carried out with those simple orchestration techniques and without a dedicated container orchestration platform.

If you are using virtual machines, or even physical machines, you might not understand some of the performance benefits you are getting out of those environments (which is why many tech-savvy companies still use them for high-performance workloads). If you move to more containerized, higher-abstraction workloads, you just might encounter performance degradations you are not expecting.

Summary
Whatever your complaints may be about your current architecture, Kubernetes is certainly not magic that will fix all or even most of your problems. My advice is to keep track of what you are happy about with your existing infrastructure and test to make sure what Kubernetes will not fail you in those areas or even make existing problems worse.

The truth is that most of us aren’t Google. We don’t always need the latest trend in software engineering, whether it’s distributed tracing or serverless or, yes, even Kubernetes. To be clear, we use all of these things to some extent at Rookout, so don’t misinterpret this article as a case against Kubernetes. Kubernetes is amazing. It just may not be for you, despite the hype.

Organizations are rapidly moving their Kubernetes applications to production to accelerate feature velocity and drive digital transformation and business growth. Our latest State of Kubernetes Security survey report shows that companies have standardized on Kubernetes, and this rapid adoption offers equal parts promise and peril. Promise, in the form of infrastructure that enables far greater inherent security than ever before. And peril, as companies struggle to overcome a skills gap and configure the technology in the most secure manner.

Kubernetes workloads – often deployed across varying environments (cloud, on-prem, hybrid) – require a security approach that is portable; protects the full container life cycle; and leverages Kubernetes’ rich context, native controls, and scalable policy enforcement to build a bridge between DevOps and Security.

The following six Kubernetes security use cases top the list of priorities for most organizations that we surveyed – follow the best practices gleaned from your peers and shared here to get your organization on the right track.

1. Runtime threat detection and response

According to our report, runtime is the life cycle phase that customers are most worried about, and more people consider runtime detection a “must have” than any others. The security goal in this phase is to detect and respond to malicious activity in an automated and scalable way while minimizing false positives and alert fatigue. Kubernetes offers rich declarative data around images and deployments that delivers valuable context when assessing runtime behavior. Leverage this context to more accurately differentiate between simple anomalies and true threats, and use Kubernetes-native enforcement capabilities to mitigate runtime threats in the most automated and scalable manner.

2. Compliance

DevOps moves fast and relies on automation for continuous improvement, so organizations need a compliance solution built to complement – not inhibit – the pace of business. You need to not only adhere to industry compliance requirements but also show evidence of that compliance. You should be able to show which clusters, nodes, or namespaces are compliant with all the individual controls relevant in container and Kubernetes environments from frameworks including CIS benchmarks for Docker and Kubernetes, PCI, HIPAA, and NIST SP 800-190. And it should be dead simple to run on-demand compliance checks and export evidence of compliance.

3. Configuration management

Misconfiguration poses the greatest security risk to containers and Kubernetes, with 67% of survey respondents experiencing a K8s misconfiguration in the last 12 months. In today’s DevOps-driven environment, configuration management must be as automated and streamlined as possible for it to not slow down application development and deployment. It should be comprehensive, covering containers, Kubernetes, and all their configurable components, including:

RBAC
Secrets
Network policies
Privilege levels
Resource limits/requests
Read-only root file systems
Annotations, labels
Sensitive host mount and access
Image configuration, including provenance

4. Vulnerability scanning and management

Most organizations start with vulnerability management – the challenge is to quickly move beyond the limited value provided by image scanning. Organizations must also identify vulnerabilities in Kubernetes, and they need a way to quickly pinpoint newly discovered vulnerabilities in already running deployments. Start with vulnerability management, but demand more than image scanning for this use case.

5. Visibility

Gaining visibility into your container and Kubernetes environments is at the root of being able to properly secure that environment. Only when your security tooling is fully embedded into Kubernetes can you understand your cloud-native infrastructure, including images, containers, pods, namespaces, clusters, and network policies. You need insights into how each is configured and whether they’re compliant with industry standards and your internal security policies.

6. Network segmentation

Containers pose a unique networking challenge because containers communicate with each other across nodes and clusters (east-west traffic) and outside endpoints (north-south traffic). Kubernetes provides built-in capabilities that enable network segmentation. Leverage those native controls to ensure consistent, portable, and scalable network segmentation regardless of your CNI plugin or Kubernetes distribution. Using the segmentation inherent in Kubernetes ensures that security and DevOps see and act on a single source of truth and consistent information to restrict access and reduce the blast radius.

The Cloud Native Computing Foundation (CNCF) has graduated Rook, an open source storage orchestrator for Kubernetes clusters, at a time when the number of stateful applications being built and deployed using containers is starting to increase.

Rook automates deployment, bootstrapping, configuration, provisioning, scaling, upgrading and migration of storage services on Kubernetes platforms in addition to enabling disaster recovery, monitoring and resource management.

Jared Watts, a Rook maintainer and founding engineer for Upbound, a provider of an open source platform for private clouds, says each storage service made is configured using Kubernetes Operator tools. Storage platforms supported by Rook include Ceph, EdgeFS, CockroachDB, Cassandra, NFS and Yugabyte DB.

In effect, Watts says Rook builds on much of the work the storage interest group (SIG) within the Technical Oversight Committee for Kubernetes has advanced to enable Kubernetes clusters to access various types of persistent storage.

Since becoming an incubating project within the CNCF in September 2018, the core Rook repository has seen its contributors grow to 279 from 90, a 260% growth rate. According to the CNCF, 184 distinct contributors have authored more than 1,140 pull requests over the last 12 months. A security audit was performed by the CNCF Security SIG in December that resulted in 13 findings ranging in severity from High to Low. The Rook maintainers have taken steps to address these issues, says Watts.

Organizations that have deployed Rook in production environments include the California Institute for Telecommunications and Information Technology, Cloudways, Finleap Connect, Geodata and RadioSound.

Interest in deploying stateful applications on Kubernetes clusters is on the rise in part because many organizations don’t want to rely on a separate team to manage storage externally. It’s more cost-effective to enable the same IT staff that manage the Kubernetes cluster to also manage all the storage resources attached to that cluster.

Historically, most of the container applications deployed on Kubernetes were stateless to the degree they typically stored data on a legacy database. However, as more databases are deployed on Kubernetes clusters, the number of stateful applications being deployed has increased. As the number and types of stateful applications increase, there is an increasing need to automate storage management tasks across fleets of Kubernetes clusters that may have very different storage services attached.

It’s not clear to what degree traditional storage vendors will embrace Rook. In the meantime, early adopters of stateful applications are moving ahead with an open source platform that enables them to manage a wide variety of heterogeneous storage services without worrying about becoming locked into a specific storage system.

Regardless of the path forward, the days when IT organizations paid a premium to store data are coming to an end. As storage software is disaggregated from hardware, it becomes easier for IT teams to replace industry-standard drives as see fit. It may take a while for storage administrators to appreciate that fact, but like it or not storage systems, just like every other IT infrastructure platform, is being turned into code.

Kubernetes has become quite the buzz word within the enterprise and for good reason.

Demand for job candidates with Kubernetes skills has increased in recent years as more organizations use this container management technology. According to Indeed, between October 2015 and October 2019, the share of Kubernetes jobs per million grew by 2,141%, while the share of Kubernetes job searches increased 2,125%.

Kubernetes is an open source container orchestration system that is used for automating computer application deployment, scaling, and management. In short, with Kubernetes, enterprises can become more agile and applications become much easier to deploy and manage.

Kubernetes can be installed in an on-premise data center or can be run from third-party hosts such as Amazon Web Services, Google Cloud Platform, Azure, etc.

The TechRepublic Premium ebook Kubernetes: Ultimate IT pro’s guide takes a deep dive into all things Kubernetes including security best practices and how-to articles detailing steps to install, deploy, and patch Kubernetes, and so much more.

For example, the Kubernetes: Ultimate IT pro’s guide ebook details how to deploy a multi-container pod or LAN-accessible pod to a Kubernetes cluster, how to add Kubernetes support to Docker desktop, and how to scale a deployment within a Kubernetes cluster.

Kubernetes is an incredibly powerful container management tool. If you’ve worked with containers long enough, you know that security must take a central role in the deployment of apps and services. The Kubernetes: Ultimate IT pro’s guide ebook explains how to create a Kubernetes security policy and discusses container security best practices.

In addition, the ebook reveals Kubernetes certifications courses, bug bounty programs, and container management tools to help troubleshoot any problems with Kubernetes.

Check out the TechRepublic Premium ebook: Kubernetes: Ultimate IT pro’s guide and learn more about why Kubernetes is one of the most flexible and powerful container managers on the market today.

Backup solutions provider Veeam Software has acquired Kasten, market leader for Kubernetes backup and disaster recovery, for $150 million in a cash and stock deal.

The acquisition will help Veeam and Kasten’s modern data management platform speed the production deployment of container-based applications.

“With the acquisition of our partner Kasten, we are taking a very important next step to accommodate our customers’ shift to container adoption in order to protect Kubernetes-native workloads on-premises and across multi-cloud environments,” said Danny Allan, Chief Technology Officer and Senior Vice President of Product Strategy at Veeam.

Veeam will integrate Kasten into its market-leading Cloud data management platform for modern data protection and radically simplify data management for enterprises.

Containers are a critical component of the DevOps-led infrastructure and application modernisation, and Kubernetes has emerged as the dominant container orchestration platform – creating a significant opportunity for a single data protection platform that includes virtual, physical, cloud and Kubernetes environments.

With the Kasten K10 Data Management Platform, Veeam will now be able to offer enterprise operations teams an easy-to-use, scalable, and secure system for Kubernetes backup and application mobility with unparalleled operational simplicity.

Niraj Tolia, CEO at Kasten, said that the company’s innovation in Kubernetes-native data management combined with Veeam’s expertise in Backup, both on-premises and in multi-cloud environments, will significantly advance the state of modern data management.

Kasten will operate as a separate Kubernetes Business Unit (BU) within Veeam. Kasten’s founders, Niraj Tolia and Vaibhav Kamra, will lead the business unit.

The Kubernetes architecture, which debuted as an open source project in 2014, is no longer very new. But there are many new dimensions to the ecosystem surrounding Kubernetes, which has changed remarkably in just the past year. Not only has Kubernetes itself continued to evolve and (arguably) finally reach maturity, but acquisitions and other major moves by vendors in the market have carried important implications for the way Kubernetes is created and consumed.
1. The Kubernetes market is consolidating.
Perhaps most obvious is that the Kubernetes market is consolidating around very large software vendors.

The most recent, and most significant, move in this vein was SUSE’s acquisition in July 2020 of Rancher, which focuses on Kubernetes management software. The deal gives SUSE, a venerable open source company whose absence from the container/Docker/Kubernetes space seemed peculiar, a chance to gain a more equal footing with other open source companies like Canonical and Red Hat, which have invested heavily in the Kubernetes architecture and related technologies.

Speaking of Red Hat, its purchase by IBM meant that OpenShift, a leading Kubernetes-based application deployment platform, is now owned by one of the world’s largest and oldest major tech firms. Not only that, but Red Hat’s acquisition of CoreOS in 2018, prior to the Red Hat-IBM deal, snuffed out another smallish Kubernetes company.

Meanwhile, in the land of the public cloud, managed Kubernetes services, like AKS and EKS, have come into their own. Introduced a few years ago, these services make it easier to deploy and manage Kubernetes.

What all of this adds up to is significant consolidation in the Kubernetes space. If you want to deploy the Kubernetes architecture today, you’ll likelier than not do it on a platform owned by a huge software company without any particularly strong history of commitment to the open source space. SUSE stands out as an exception in this context, but even it is a much larger company than Rancher.
This is a big change from a few years ago, when most organizations that wanted to use the Kubernetes architecture were relying on solutions from startups, or doing it themselves. There are still vendors that cater to this market (Platform9, which provides Kubernetes management for infrastructure of any size), but, for the most part, Kubernetes seems like it has been corporatized, so to speak.

2. VMware comes to Kubernetes architecture.
For a long time, VMware and Kubernetes occupied decidedly different corners of the IT ecosystem.

That has changed over the course of the past year, thanks to VMware’s launch of Project Pacific and Tanzu. With these offerings, VMware is not only competing with Kubernetes management tools from other vendors, but is also trying to build a solutions stack that allows users to manage virtual machines and containers through the same framework.

That makes good sense–there will always be some workloads that can’t be containerized, and being able to use the Kubernetes architecture as a common management solution for both containers and virtual machines helps to consolidate and simplify workflows.

Other projects, like KubeVirt, are doing the same thing, but in a more vendor-agnostic way. Whether VMware’s Kubernetes play ends up succeeding in the long run will depend, I suspect, on how much of VMware’s current customer base–which is invested heavily in virtual machines–the company can migrate to a container-first, cloud-native strategy using its tooling. I have a hard time seeing organizations that don’t already have an investment in the VMware ecosystem choosing to use VMware as their onramp to Kubernetes.
In this sense, VMware’s Kubernetes strategy feels at once both predictable and like a move out of left field. I’m tempted to compare it to Michael Bloomberg’s 2020 primary run, although I’m not yet ready to say whether the former will enjoy more success than the latter.

3. Kubernetes goes multi-cluster and multi-cloud.
Once upon a time, the Kubernetes architecture was designed with the expectation that you’d be running only one cluster. That’s why there are namespaces, which let you segment workloads within a cluster.

But over the past year or two, Kubernetes vendors have dispensed with that constraint. Platforms like Rancher and VMware Tanzu Mission Control have made management of multi-cluster Kubernetes architectures a key selling point. Now, if you want full isolation between your workloads, you can host each one in its own cluster, rather than relying on namespacing alone.

Not only that, but the Kubernetes architecture has also evolved into a solution for multi-cloud and hybrid cloud management in the form of Anthos, a platform that Google introduced in 2019. Anthos uses Kubernetes as an abstraction layer between underlying infrastructure and applications, allowing users to deploy and manage workloads in a uniform way across multiple clouds or on-premises data centers.

Today, then, the Kubernetes architecture is all about giving users freedom to deploy as many clusters as they want on as many clouds (or on-premises environments) as they want.

4. Google continues to dominate Kubernetes development.
On the one hand, it may not seem surprising that Google remains by far the lead contributor to Kubernetes. Kubernetes powers Anthos, as well as Google Cloud’s Kubernetes Engine. And Kubernetes originated out of an internal Google project called Borg.

On the other hand, it has been more than six years since Google birthed Kubernetes into the open source community. In that time, the Kubernetes space has become so large and diverse that it’s surprising that other companies aren’t more active in Kubernetes development. Red Hat/IBM comes in at a distant second behind Google, and vendors like Amazon don’t even make the top 10 list of Kubernetes contributors. Looking at the Kubernetes marketplace as a whole, you might expect Google to be less dominant than it is in developing Kubernetes itself.
Conclusion
In short, the Kubernetes world has become smaller, with major software companies like Google, VMware, IBM, Microsoft and Amazon playing a more dominant role in the ecosystem than ever. But that doesn’t mean Kubernetes does not continue to evolve to support new use cases, most notably multi-cluster and multi-cloud deployments.

What comes next? Even more consolidation seems likely; I’d be surprised if many smaller Kubernetes vendors continue to hold out as independent enterprises over the coming years. I also suspect that the Kubernetes architecture will continue to play an even greater role in the world of hybrid cloud, with vendors other than Google investing in solutions similar to Anthos. And activity in the Kubernetes space as a whole may level off as the technology becomes less disruptive and more an everyday part of solutions stacks.