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

In the previous article, we shared 9 Kubernetes security best practices that CNCF recommends for Kubernetes users and 9 basic actions that can further ensure cluster security when users use Kubernetes to manage clusters.

The suggestions in the previous article were excellent, but the downside was that they relied too heavily on GKE. For those who use Google services, GKE is certainly a good solution. However, there are many more people who are running Kubernetes clusters on Amazon, Azure, Alibaba Cloud, Huawei Cloud, DigitalOcean, or even their own infrastructure or wherever they want, so at this time,GKE related solutions are not very helpful to them.

For these users, Rancher is a great choice as an open source solution.

Rancher Labs takes security seriously. Darren Shepherd, co-founder and chief architect of Rancher Labs, was the discoverer of Kuberntes 'first serious security vulnerability (CVE-2018-1002105) in late 2018. Security should not be an afterthought, nor should it be something to remember to do after deploying an insecure cluster. Just like when you build a house, you shouldn't put everything in before you start installing locks.

In this article, I'll review each of the points CNCF raised in the previous article and show you how Rancher and RKE can meet these security recommendations in their default settings.

upgrade to the latest version

This is reasonable advice, and it doesn't just apply to Kubernetes. Because unpatched programs are often the entry point for ***. When a security vulnerability appears and poc code becomes publicly available, tool suites like Metasploit quickly include it in their standard suite. At this point, anyone who can copy and paste commands from the Internet can control your system.

When using Rancher Kubernetes Engine (RKE), you can choose which version of Kubernetes to install, either alone or with Rancher. Rancher Labs uses native upstream Kubernetes, which enables companies to quickly respond to security alerts and release fixed versions of the software. Because RKE runs Kubernetes components in Docker containers. Operations teams can upgrade critical infrastructure with zero downtime.

You can receive information about the new release through Rancher's GitHub homepage, Weixin Official Accounts, official website and other channels. I also strongly recommend that you test the new version in the staging environment before upgrading. Rancher can also easily roll back to previous versions if the upgrade goes wrong.

Enable Role-Based Access Control (RBAC)

RBAC starts by default after RKE is installed. If you are using only RKE or any other standalone Kubernetes deployment, you are responsible for configuring accounts, roles, and bindings to protect your cluster.

If you are using Rancher, it not only installs security clusters, but also proxies all communication with those clusters through the Rancher server. Rancher can plug in many backend authenticators such as Active Directory, LDAP, SAML, Github, etc. When connected in this way, Rancher enables you to extend existing enterprise authentication to all Kubernetes clusters under Rancher's umbrella, regardless of where those clusters run.

Rancher enables roles at the global, cluster, and project levels, enabling administrators to define roles in one place and apply them to all clusters. This combination of RBAC-by-default and strong authentication and authorization controls means that the cluster is secure from the moment it is deployed using Rancher or RKE.

Using namespaces to establish security boundaries

Because of the special way Kubernetes handles the default namespace, I don't recommend using it. I recommend that you create a namespace for each application and define them as logical groups.

Rancher defines an additional abstraction layer called Project. A Project is a collection of namespaces on which roles can be mapped. Users may have access to a Project, but they cannot see or interact with any workloads running in any Project they do not have access to. This effectively creates a single cluster with multiple tenants.

Projects makes it easier for administrators to grant access to multiple namespaces in a single cluster. It minimizes duplication and human error.

Separate sensitive workloads from each other

This is good advice because it assumes the question,"What happens if the workload is compromised? "。Taking action ahead of time can reduce the scope of damage and make it more difficult for the *** to upgrade privileges, but it is not entirely impossible. So this may take you extra time to process.

Kubernetes allows you to set taints and torrements to control where pods may be deployed.

Rancher also allows you to control the scheduling of workloads through Kubernetes tags. In addition to stains and tolerances, when deploying workloads, you can set labels that hosts must, should, or can have, and these labels control where pods are deployed. If your environment is static, you can also schedule workloads to specific nodes.

Secure cloud metadata access

The recommendation states that sensitive metadata "can sometimes be stolen or misused," but fails to outline "when" or "how" conditions. The leak of Shopify's bounty details was mentioned in the previous post and was mentioned at KubeCon North America on December 13, 2018. Although the previous article pointed out that GKE has "metadata hiding" functionality, it is worth noting that the service that leaked credentials in the first place was the Google Cloud metadata API.

Furthermore, there is no evidence that any other cloud provider has the same vulnerability.

The only location where this vulnerability could exist is hosted Kubernetes services such as GKE. If you deploy RKE directly or through Rancher onto bare metal or cloud instances, you end up with a cluster that cannot leak credentials through the cloud provider's metadata API.

If you are using GKE, I recommend that you activate this feature to prevent any credentials from leaking through metadata services. I also believe cloud providers should not embed credentials into metadata that is accessible through APIs. Even if this is done for convenience, it is an unnecessary risk that could have unimaginable consequences.

Create and define cluster network policies

RKE clusters deployed directly or by Rancher use Canal by default, although you can also choose Calico or Flannel. Both Canal and Calico support network policies. When using Canal as the network provider, the clusters deployed by Rancher also support Project network policies. Once activated, workloads can communicate with other workloads in their projects, while system projects (including cluster-wide components such as ingress controllers) can communicate with all projects.

Earlier versions of Rancher enabled Project network policies by default, but this caused confusion for users who were unaware of the extra security. Therefore, in order to provide the best experience for users, this feature is now turned off by default, but can also be easily activated after startup if you want to enable it.

Run cluster-wide Pod security policies

Pod security policies (PSPs) control that pods must have certain features and configurations in order to function in a cluster. For example, you can block privileged mode, host networking, or run containers as root. When installing clusters via Rancher or RKE, you can choose whether you want restricted PSP enabled by default. If you choose to enable it, your cluster will immediately enforce enforced restrictions on workload permissions.

Restricted and unrestricted PSPs are the same in RKE and Rancher, so what they activate at installation is the same. Rancher allows an unlimited number of additional PSP templates, all of which can be processed globally. Administrators define PSPs and then apply them to each cluster Rancher manages. Similar to the RBAC configuration discussed earlier, it keeps security configurations in one place and greatly simplifies policy configuration and application.

Strengthen node security

This is not Kubernetes-specific advice, but a good universal strategy. When you want to interact with traffic that you can't control (for example, user clicks on an application running in Kubernetes), you should let it run on a node with a smaller *** face. In addition, disabling and unloading unwanted services is also necessary. Also, root access should be restricted via SSH and sudo password encryption is required. Use a passphrase on the SSH key, or bind the key to a user-owned device using services such as 2FA, U2F key, or Krypton. These are examples of basic standard configurations for safety systems.

Rancher does not require anything else on the host other than supported Docker versions. Also, RKE only requires SSH access, and it will install the latest version of Docker supported by Kubernetes before proceeding with the installation of Kubernetes.

If you want to reduce the number of *** faces even further, check out RancherOS, a lightweight Linux operating system that runs all processes as Docker containers. System Docker runs only the minimum number of processes needed to provide access and runs Docker instances in user space for actual workloads.

Enable Audit Logging

Rancher servers can run inside RKE clusters, so in addition to Kubernetes audit logs, it is important to activate audit logs for API calls to the server itself. This log will show all actions performed by the user on any cluster, including the events that occurred, who performed the action, when the action was performed, and the cluster that performed the action. It is also important to send these logs from the server in question. Rancher can connect to Splunk, Elasticsearch, Fluentd, Kafka, or any system log endpoint from which you can generate dashboards and alerts for suspicious activity.

For information on enabling audit logs for Rancher servers, see our documentation.

（https://rancher.com/docs/rancher/v2.x/en/admin-settings/api-audit-log/ ）

For information about enabling audit logs for RKE clusters, see the next section.

Security operations ongoing

True protection of Kubernetes clusters requires more than nine actions, and Rancher has a security hardening guide (rancher.com/docs/rancher/v2.x/en/faq/security/) and a self-assessment guide (releases.rancher.com/documents/security/latest/Rancher_Benchmark_Assessment.pdf) covering more than 100 controls CIS benchmarks use to protect Kubernetes.

If you care about security, Rancher, RKE, and RancherOS will help you.

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.