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

Last month, Kubernetes, the world's most popular container orchestration engine, revealed its first serious security breach, shaking the whole Kubernetes ecosystem. The vulnerability (CVE-2018-1002105) allows people to destroy the cluster through the Kubernetes API server, allowing them to run code to perform malicious activities, such as installing malware.

Earlier this year, Tesla was infected by a malicious cryptocurrency mining software due to a configuration error in the Kubernetes console. * users take advantage of the lack of password protection in a specific Kubernetes console to access one of the pod that contains Tesla's access credentials for a large AWS environment.

As more and more enterprises begin to use containers and container orchestration engines, they need to take the necessary steps to protect this critical part of the computer infrastructure. To help you do this, this article will introduce you to nine Kubernetes security best practices.

01 upgrade to the latest version

Each quarterly update adds new security-related features, not just fixing bug, and to take full advantage of these security features, we recommend that you always run the latest stable version.

02 enable role-based access control (RBAC)

Controls who can access Kubernetes API and their permissions on role-based access control (RBAC). By default, RBAC is usually enabled in Kubernetes 1.6 and later, but if you have upgraded since then and have not changed the configuration, you need to carefully check your settings. Because of the way Kubernetes authorization controllers are combined, you must also enable RBAC and disable traditional attribute-based access control (ABAC).

After enabling RBAC, you also need to use it effectively. In order to license a specific namespace, you usually need to avoid cluster-wide permissions. Even for debugging purposes, you should avoid giving any cluster administrator privileges, but only grant access on a case-by-case basis if necessary to improve security.

You can use kubectl get clusterrolebinding or kubectl get rolebinding-all-namespaces to explore cluster roles and roles. At the same time, quickly check who has been granted the special "cluster-admin" role, which in this case is the "master" group:

If your application needs to access Kubernetes API, create a separate service account and provide each site with the minimum set of permissions required. This is better than granting overly broad permissions to the default account of the namespace.

Most applications do not need to access API at all, in which case automountServiceAccountToken can be set to "false".

03 use namespaces to establish security boundaries

Creating separate namespaces is an important first layer of isolation between components. When different types of workloads are deployed in different namespaces, we find it much easier to apply security controls, such as network policies.

Is your team using namespaces efficiently? Check those non-default namespaces to confirm:

04 separate sensitive workloads from each other

To minimize the potential damage impact, it is best to run sensitive workloads on a set of dedicated computers. This approach reduces the risk of accessing sensitive applications through less secure applications of shared container runtimes or hosts. For example, the kubelet credentials of a compromised node can usually access confidential content only when it is installed in the pod arranged on that node, and if important secrets are assigned to many nodes in the entire cluster, the * will have more opportunities to steal them.

You can use node pools (either in the cloud or locally) and Kubernetes namespaces, taints, tolerations, and other controls to achieve this separation.

05 secure cloud metadata access

Sensitive metadata, such as kubelet administrator credentials, is sometimes stolen or abused to upgrade permissions in the cluster. The recent disclosure of details of Shopify's reward bug is a case in point. This shows that users can upgrade their privileges by confusing microservices with the disclosure of information from the cloud provider's metadata services. GKE's metadata hiding feature can change the cluster deployment mechanism to avoid this exposure, and we recommend that you use this feature until you find another permanent alternative. Similar responses may be needed in other environments.

06 create and define cluster network policies

Network policies allow you to control network access to and from containerized applications. To use them, you need to ensure that you have a network provider that supports this resource, and for some managed Kubernetes providers, such as Google Kubernetes Engine (GKE), you need to choose to join. If your cluster already exists, enabling network policy in GKE requires a short rolling upgrade. Once in place, start with some basic default network policies, such as blocking traffic from other namespaces by default

If you are running in GKE, you can check that the cluster is running with policy support enabled:

07 run cluster-wide Pod security policy

The Pod security policy sets the default values that allow workloads to run in the cluster. Consider defining policies and enabling the Pod security policy license controller, which varies depending on the cloud provider or deployment model. First, you can ask the deployment to give up the NET_RAW function to protect against some types of network spoofing.

08 strengthen node security

You can follow these three steps to improve the security state on the node:

Ensure that the host is secure and configured correctly. One way is to check your configuration against the CIS benchmark, and many products have an automatic check feature that automatically evaluates whether the configuration conforms to these standards.

Controls network access to sensitive ports. Make sure your network blocks access to the ports used by kubelet, including 10250 and 10255. In addition, you need to restrict access to Kubernetes API servers outside the trusted network. Because malicious users are likely to abuse access to these ports to run cryptocurrency miners in clusters that are not configured and require authentication and authorization on the kubelet API server.

Minimize administrative access to Kubernetes nodes. In general, access to nodes in the cluster should be restricted because debugging and performing other tasks can be done without directly accessing the nodes.

09 enable audit log (Audit Logging)

Make sure that you have enabled audit logs and monitor them for abnormal or unwanted API calls, especially any failed authorization-- these log entries will display the status "Forbidden". The failure of authorization may mean that the person trying to misuse the stolen credentials. Managed Kubernetes providers, including GKE, can access this data in their cloud console and allow you to set authorization failure alerts.

By following the nine recommendations above, you can get a more secure Kubernetes cluster. Keep in mind that even if you have securely configured your Kubernetes cluster in full accordance with the steps above, you still need to build security into other aspects of the container configuration and its runtime operations. When you improve the security of the technology stack, you need to find tools that provide a central governance point for container deployment and provide continuous monitoring and protection for container and cloud native applications.

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.