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

Recently, security problems have been found in connection between the Kubernetes dashboard and the external IP agent. In response to these two vulnerabilities, Kubernetes has released a corresponding patch version for users who will be affected by the vulnerability to solve the problem. This article will take a closer look at the principles of these two security vulnerabilities, their impact on your Kubernetes deployment, and how to deal with them.

Access custom TLS certificates through the kubernetes dashboard

The Kubernetes dashboard vulnerability (CVE-2018-18264) affects v1.10.0 or earlier dashboard versions. Because of this vulnerability, users can "skip" the login process, assume a configured service account, and end up with a custom TLS certificate used by the dashboard. If you have configured the Kubernetes dashboard to require login and configure it to use a custom TLS certificate, this vulnerability will affect you and you need to be aware of it.

How the vulnerability works

This vulnerability can be explained in two parts.

The first is that because users can choose the "skip" option when logging in, any user can bypass the login process, which is always enabled by default in v1.10.0 or earlier. In this way, the user completely skips the login process and can use the service account configured by the dashboard.

The second is that service accounts configured with dashboards must have minimal access to custom TLS certificates (stored in the form of secret). Unauthenticated logins, coupled with the dashboard's ability to retrieve these secret using configured service accounts, result in this security issue.

When using the dashboard v1.10.1 patch, the Skip option is no longer enabled by default, and the dashboard's ability to retrieve and display it in UI is disabled.

What does this vulnerability mean for Rancher 1.6.x and 2.x?

In Rancher 2.x, Kubernetes dashboards are not enabled by default because the Rancher 2.0 user interface can be used as an alternative. If you do not use the dashboard code base, you will not be affected by this vulnerability. If you change the default settings and deploy Kubernetes dashboards on any Kubernetes cluster managed by Rancher, be sure to use the official Kubernetes guidelines and patches to fix this vulnerability.

If you are using Rancher 1.6.x, don't worry at all. In Rancher 1.6.x, the Kubernetes dashboard is included as part of each Kubernetes cluster environment; however, the 1.6.x deployment is not affected because Rancher Server acts as the authentication authority and agent for the Kubernetes dashboard. It does not take advantage of the default Kubernetes dashboard login mechanism. In addition, the Kubernetes dashboard deployed by Rancher does not use any custom TLS certificates.

Kubernetes API server external IP address proxy vulnerability

Let's explore the second vulnerability described in the Kubernetes announcement.

The Kubernetes API server proxies requests to the pod or node using a node, node, or service proxy API. Proxy requests can be directed to any IP by directly modifying the podIP or nodeIP. The API server is always deployed in a network, and this vulnerability can be exploited to access any available IP in that network. Although Kubernetes has greatly increased its checks to alleviate this problem since the v1.10 release, it has only recently been discovered that the problem of a path has not been fully resolved-pointing the agent to the local address to the host running the API server.

How the vulnerability works

By using Kubernetes API, users can use a node agent, pod agent, or service agent API to request a connection to a pod or node. Kubernetes accepts the request, finds the associated IP of podIP or nodeIP, and eventually forwards the request to that IP. These are usually assigned automatically by Kubernetes. However, the cluster administrator (or different roles with similar "superuser" privileges) can update the podIP or nodeIP fields of the resource to point to any IP.

This is largely not a problem, because "normal" users cannot change the podIP or nodeIP of a resource. The podIP and nodeIP fields are located in the state child resources of the pod and node resources. In order to update status subresources, RBAC rules must be specifically granted. By default, except for the cluster administrator and internal Kubernetes components (such as kubelet, controller-manager, scheduler), no Kubernetes role can access the state subresources. To exploit this vulnerability, you must first have high-level access to the cluster.

The fix officially released by Kubernetes this time is to make sure that the * * vector can exist in the settings of the management dashboard separate from the cluster. In this case, the cluster administrator cannot access the host running the API server. This situation exists in managed Kubernetes services that you get from a cloud provider. In this case, the cluster administrator can access the local address of the API server by changing podIP / nodeIP to a local address, such as 127.0.0.1. The fix released today will prevent the agent from going to the local address.

What does this mean for Rancher users?

Default permissions for Rancher managed clusters, which only allow cluster owners and members to change podIP or nodeIP fields. When providing this permission to other users, it must be assumed that the user is allowed full access to any node in the cluster. All other default roles, such as project owners / members, do not have access to these fields. The hotfix released today applies to a deployed Kubernete cluster whose control panel network is different from the network used by the application. Kubernete clusters created in Rancher 1.6.x or 2.x default that the cluster administrator has full access to the dashboard nodes. If you are using Rancher 2.x and you are using a managed cloud provider (such as EKS, GKE, AKS), check with them to see if there is a security problem, as the dashboard is owned by the cloud provider.

We always want to ensure that Rancher users have access to the latest security fixes and patches in the shortest possible time. Kubernetes versions v1.10.12, v1.11.6, and v1.12.4 address these two security vulnerabilities, and these three versions of Kubernetes will be available in Rancher versions v2.1.5 and v2.0.10. If you are a user of Rancher v1.6.x, you do not need to make any updates, as the standard v1.6.x installation is not affected by this security vulnerability.

You can also learn about Kubernetes' official discussion of these two vulnerabilities through the following two links:

Https://discuss.kubernetes.io/t/security-release-of-dashboard-v1-10-1-cve-2018-18264/4069

Https://discuss.kubernetes.io/t/security-impact-of-kubernetes-api-server-external-ip-address-proxying/4072

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.