4 Kubernetes security challenges and how to address them

Source:-techbeacon.com

The widespread use of Kubernetes is testament to enterprises’ faith in their ability not just to handle the complexity of modern app development and modernization initiatives, but to do so at scale.

According to a recent survey of 1,340 technical experts in companies of all sizes, conducted by the Cloud Native Computing Foundation (CNCF), 78% of respondents are using the open-source container orchestration tool in production. This is up from just 58% last year.

But while Kubernetes is one of the most popular projects on GitHub, many organizations are still intimidated by its complexity.

Organizations have seen the value of building microservices—delivering applications as discrete functional parts, each of which can be delivered as a container and managed separately. But for every application there are more parts to manage, especially at scale.

Kubernetes solves that problem by providing an extensible, declarative platform that automates the management of containers for high availability, resiliency, and scale. But Kubernetes is a big, complex, fast-moving, and sometimes confusing platform that requires users to develop new skills. The Kubernetes project itself recently completed a security audit. (Here’s what admins need to know about it.)

Companies developing their cloud-native strategies, including what platforms and tools they should use to ensure the safe deployment of cloud-native apps, may benefit from understanding Kubernetes’ security challenges, which fall into four main buckets.

Here are the challenges you’ll face, and recommendations for mitigating them.

[ Get up to speed on IT Operations Monitoring with TechBeacon’s Guide. Plus: Download the Roadmap to High-Performing IT Ops Report ]

1. Hardening and compliance

When using Kubernetes, you must be hyperfocused on what is and is not turned on by default. For example, pod security policies are key to securing a multi-tenant cluster, but the feature is still beta and is not turned on by default. The feature-rich Kubernetes platform can make it challenging to understand the default features, but it is essential to figure it out.

Organizations can use security benchmarks to help harden Kubernetes. The Center for Internet Security, for example, provides configuration guidelines to harden systems, including Kubernetes, against evolving cyber threats.

Having this type of step-by-step checklist can go a long way toward securing a system as complex as Kubernetes. However, since security is always about risk management, organizations need to evaluate the impact of certain settings on performance and weigh the risks versus the benefits.

Some organizations don’t have the skillsets or time to harden Kubernetes on their own. It can be a huge job to ensure that the desired configuration of the cluster is set and maintained to include things such as ensuring access to the API server is always over HTTPS, that X.509 certificates are used to authenticate communication between platform components, or that the etcd datastore is encrypted.

Organizations that are overwhelmed by even this relatively short list might want to consider a commercial implementation of Kubernetes that has already done the hardening.

2. Managing configurations of all workloads deployed on the cluster

In addition to managing the configuration of the cluster, organizations need to manage the configurations of all the workloads running on the cluster. You can use the open-source tool Helm Charts to automate application provisioning and configuration for Kubernetes as well as to deploy simple or complex applications made up of several separate services.

However, while Helm is very useful for managing Day 1 operations, it does not extend to Day 2 operations, which is where Kubernetes operators shine.

Operators are a way to package, deploy, and manage complex applications designed to run on Kubernetes. Operators take human operational knowledge and encode it into software that is packaged with the application and shared.

They make it easier for application developers to deliver automated lifecycle management for the services that run on Kubernetes. Helm Charts can also be wrapped in a Kubernetes operator and used together.

When it comes to security, operators ensure that services deployed on Kubernetes maintain supported configurations; if an unsupported configuration is made to a deployed service, operators can reset the service to its original, declared configuration.

The really interesting thing is that you can use Kubernetes operators to manage Kubernetes itself, making it easier to deliver and automate secured deployments.

[ Robotic Process Automation can do mundane tasks, allowing you to get strategic. Find out how in this April 28 Webinar. Plus: Learn how to roll out RPA with TechBeacon’s Guide. ]

3. Managing multi-tenant clusters

As Kubernetes scales, it becomes more and more difficult to manage all workloads deployed on the clusters and the clusters themselves. Multi-tenancy is one of the most effective ways to handle what could easily become chaotic. Indeed, Kubernetes’ support for multi-tenancy has come a long way.

Key capabilities include the following, (which, you should note, are not always turned on by default):

Namespaces, which allow organizations to isolate multiple teams within the same physical cluster when used with RBAC (defined below) and network policies.

Role-based access control (RBAC) determines whether a user is allowed to perform a given action within a cluster or namespace. To help simplify the use of RBAC, consider the use of default roles that can be bound to users and groups cluster-wide or locally per namespace.

Resource quotas in Kubernetes limit aggregate resource consumption per namespace, making systems less vulnerable to attacks such as denial of service. By default, all resources in a Kubernetes cluster are created with unbounded CPU and memory requests/limits.

Network policy for micro-segmentation specifies how groups of pods communicate with each other and other network endpoints. Policies are namespace-scoped. By default, if no policies are set in a namespace, ingress and egress traffic is allowed to and from pods in that namespace.

4. Balancing security and agility

The pressure is on for organizations to constantly innovate, which makes it easy to treat security as an afterthought. Ideally, security is built into the DevOps cycle, but organizations will benefit by explicitly adding “sec” into the middle of DevOps—or, put another way, by building as much security automation into the pipeline as possible.

To ensure that app dev organizations can implement security best practices, take a step back and revisit your CI/CD pipelines. Are they using automated unit and functional tests? Have they integrated automated security gates such as integrated vulnerability scanners?

Ops can help with DevSecOps by adding features to both development and production clusters that make it easy for the app dev team to leverage monitoring, alerting, and logging services in a uniform way while developing and deploying microservice-based apps.

In addition, while adding a service mesh to a Kubernetes cluster may seem to add complexity, it’s actually making important business logic more visible. Previously, developers needed to build the logic into their code. Now, these capabilities can be made available as part of the Kubernetes platform, saving developers work and accelerating the delivery of microservices.

A service mesh also provides more visibility for microservice interactions to the operations team, especially when observability and visualization of east-west cluster traffic are included as part of the service mesh solution.

But this is not just about tools; it’s also about culture and process. Ideally, this kind of self-assessment work, along with changes to the CI/CD pipeline, is done in collaboration with the organization’s security team, creating an opportunity for developers to learn more about security and vice versa. After all, there’s a shortage of security professionals, so let’s work together and spread the wealth.

Use the tools and techniques at your disposal

Build security capabilities into your software that make it as easy as possible for your organization to meet its security goals without having to rely on a large collection of point products that may or may not work well together.

It’s terrific to see the Kubernetes community invest not only in traditional security evaluations, such as the Kubernetes security audit, but also in the full spectrum of capabilities that enhance security, including hardening guidance, RBAC, pod security policies, network policies, service mesh, and operators.

Want to know more? During my KubeCon + CloudNativeCon Europe conference session, “Kubernetes and Cloud Native Security: A State of the Union,” I’ll offer my take on the overall state of Kubernetes with regard to cloud-native security, and steps to take to address the most common challenges.