Shulou(Shulou.com)06/02 Report--

There is no doubt that K8s has become the standard of cloud container orchestration system. However, if there is no understanding of security issues related to K8s environment, various components will be exposed inside and outside the network cluster. This article describes how to ensure that an enterprise's K8s cluster is protected from external * through strong authentication.

This is the first in a three-part series on Kubernetes security. In this series, we will in turn look at how to ensure that an enterprise's Kubernetes cluster is protected from external and internal issues, and how to deal with resource consumption or noisy neighbors issues.

There is no doubt that Kubernetes has become the standard for cloud container orchestration systems, providing a "platform for automated deployment, expansion, and operation of application containers across host clusters," as defined by Cloud Native Computing Foundation (CNCF). However, the lack of awareness of security issues related to the Kubernetes environment will cause various components to be exposed both inside and outside the network cluster.

Lock API server, Kubelets

There are a variety of externally accessible components in the Kubernetes environment, including application programming interface (API) servers, kubelet, and data stores. If they are not properly locked and protected, these components can cause data leakage and system damage.

Kubernetes provides an API structure for development, operations and security teams that can be used to interact with applications and Kubernetes platforms. Kubelet is a service that runs on a node and reads the container list, ensuring that the defined container is up and running. Kubernetes leverages etcd distributed key-value storage to store and replicate data that Kubernetes uses throughout the cluster. Basically, the most frequent Kubernetes systems are those that have no access control at all.

Goins points out that Kubernetes is easy to deploy and doesn't have much built-in to ensure security by default. For example, it was not until mid-2017 that the container orchestration system began to have RBAC (role-based access control) functionality.

One of the highlights of Kubernetes 1.8 is RBAC (role-based access Control), an authorization mechanism for managing permissions around Kubernetes resources. RBAC allows you to configure flexible authorization policies that can be updated without the need to restart the cluster.

"in many Kubernetes deployments, once compromise appears, users can use root privileges to install and run the software they want." "* * and cyber criminals want to enter a system, upgrade their privileges, then switch to other systems and start collecting information such as credit card and personal identification data," Goins said. "

The first security vulnerability exposed in Kubernetes in December 2018, privilege escalation vulnerability (CVE-2018-1002105), was discovered by Darren Shepherd, co-founder and chief architect of Rancher Labs. This vulnerability demonstrates how a user can establish a connection to a back-end server through a Kubernetes API server. After a connection is established, the * * user can send any request directly to the back-end cluster service (such as kubelets) through the network connection. This vulnerability allows any user to have full administrator privileges on any compute node. Patches were later released specifically to fix supported Kubernetes versions, which are available in 1.10.11, 1.11.5 and 1.12.3.

How should enterprises protect K8s clusters from the outside?

Goins recommends that the first thing Kubernetes users need to do is to shut down external API access completely or encapsulate the feature in some kind of strong authentication to set protection. In order to mitigate external threats, information technology / security administrators must ensure that only necessary Kubernetes services are exposed. In addition, they must set up authentication and configure the correct network security policy for all exposed services.

Handy Tecchnologies's Alexander Uricoli wrote in a blog post: "unless you specify some flags on kubelet, it will accept unauthenticated API requests in the default mode of operation." In this blog post, Uricoli analyzes * how to * at the same time Kubernetes clusters on personal servers:

Https://medium.com/handy-tech/analysis-of-a-kubernetes-hack-backdooring-through-kubelet-823be5c3d67c

"it seems that someone has found a way to put some encryption mining software on a running container and then perform the process," Uricoli said. " Although Kubernetes API servers are exposed to internet, they are protected by certificate authentication.

As a result, the colleague's server exposed kubelet ports (tcp 10250 and tcp 10255). Uricoli pointed out that although the problem is obvious, such a * should still draw attention to some of the problems with the deployment of Kubernetes. If your users can access your nodes through network nodes, then kubelet API is an API backdoor to the cluster, fully functional and unauthenticated. If users have put a lot of effort into enabling authentication and authorization with webhook, RBAC, or other methods, they should also lock down kubelet as well.

The Internet Security Center (CIS) recommends that users deploy HTTPS for kubelet connections. In its guide to establishing a security configuration for Kubernetes 1.11, CIS wrote, "the connection from the API server to kubelets may have sensitive data such as secrets and keys. Therefore, it is very important to use in-transit in any communication between the API server and kubeletes."

Kubernetes users should disable anonymous requests to the API server. When enabled, requests that are not rejected by other configured authentication methods are considered anonymous and are then processed by the API server. According to CIS, Kubernetes users should rely on authentication to authorize access and refuse anonymous requests, while organizations should implement controllable access as needed.

Goins points out that strengthening security controls against internal cluster users-- RBAC, isolation, and permission restrictions-- is equally important to protect Kubernetes from external security.

"if someone uses any internal user's account to access the cluster from the outside, they will get full access immediately," he said. " So, this is not to say that you need internal control to defend against external control. It means that if you don't have these measures, you will suffer when you are attacked.

Conclusion

With more than 100 million downloads on the Rancher Kubernetes platform, we are well aware of the importance of security issues to users, not to mention the tens of millions of users who run Docker and Kubernetes in a production environment through the Rancher platform.

CVE-2018-1002105, the first serious security vulnerability exposed by Kubernetes at the end of 2018, was discovered by Darren Shepherd, co-founder and chief architect of Rancher Labs.

When Kubernetes revealed security vulnerabilities in dashboards and external IP agents in January 2019, Rancher Labs was also the first time in the industry to respond to users, ensuring that all Rancher 2.x and 1.6.x users were completely unaffected by the vulnerability.

In the future, Rancher will share more container and Kubernetes security tips with users. In the next blog post, we will share three ways to protect Kubernetes from internal *: role-based access, Kubernetes features (such as logical isolation, that is, namespaces), and Rancher resources (such as Project). Remember to keep paying attention.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.