Micro-isolationthree roads

If a user wants to deploy micro-segmentation in his own data center, how many options does he have? According to Gartner, it has four paths.

Four micro-isolation technology routes proposed by Gartner

The first path is the simplest. Users don’t need to install anything. The basic cloud computing platform will provide you with micro-isolation capabilities. But the problem with this approach is that it is highly dependent on the capabilities of the cloud you are using, and not all cloud platforms can provide it. At the same time, this path has obvious limitations in environmental adaptability. Micro-isolation capabilities cannot be transferred to other cloud platforms, and unified management cannot be achieved for cross-cloud architecture scenarios such as hybrid cloud and multi-cloud.

The second way, which everyone is most familiar with, is to use a virtual firewall. The advantage of this way is that everyone is familiar with the use of firewalls, but it also has problems. The firewall is oncyber securityThe isolation and segmentation technology produced in the early stages of development is designed for access control of cross-domain traffic. After certain adaptation and transformation, traditional firewalls can be deployed in cloud environments, but it is still difficult to achieve more fine-grained business-level ,workload level control. In addition, in view of the impact of policy scale on firewall performance, the control objects of its security policies can often only reach the network segment level.

The third path is a combination of the first two paths. It achieves network isolation within the data center through the complementation of the two technical route solutions.

The fourth path is by far the most successful and the path chosen by the most people. That is the host agent path. The reason why this path is difficult for users to refuse is that it has nothing to do with the infrastructure. It uses the agent and the operating system. Its wide compatibility avoids the difficulty of adapting to various cloud environment architectures, and uses the Overlay mode to build a control network that is completely decoupled from the infrastructure on top of the basic network. The benefits brought by this are obvious. Users can use this path to achieve unified management of east-west traffic across data centers and platforms. It has to be said that since most K8S network plug-ins use the inherent capabilities of the host (Node) kernel to implement network forwarding within the container platform, this path is almost naturally supported by the container platform. For a long time in the past, this path has been This road is almost the only way to achieve unified management of physical machines, virtual machines, and containers.

In view of the fact that the above third path has nothing new from a technical point of view, it is more of a "solution" than a "technical route", so there are only three possible paths in the true sense.

So is there a real fourth possibility? Or is it necessary to propose another technical path? The answer is yes.

cloud nativemicro-isolation

In fact, if it is under cloud computing conditions, the host agent basically dominates the world, and it makes no sense to propose a new technical route for the sake of being innovative. But with the advent of cloud native, things have become different.

Cloud-native operation and maintenance management logic and network construction methods are very different from traditional cloud computing. At present, at home and abroad, everyone is doing micro-isolation in cloud-native environments, which is basically implemented through host agents. Qiangwei Smart did this in the past, and in fact it did a good job.

However, just as firewalls were not born for cloud computing, implementing "micro-segmentation" in a cloud computing environment must have many incompatibilities for them. The host agent is by no means born for cloud native, and it is bound to have its own incompatibility. You must know that the Agent on the virtual machine and the Agent in cloud native are not the same Agent. The Agent in the virtual machine has a very close connection with the virtual machine. It can be said that when the moon goes, I will go, and we will always be good friends. However, the Agent in cloud native is actually deployed on the host. It is separated from the container and the entire orchestration system. This separation brings problems, that is, the operation and maintenance management of the Agent is independent of the entire orchestration system. In addition to the orchestration management of the PAAS platform, this is actually unfriendly or even contrary to the cloud-native world that advocates DevSecOps logic.

Therefore, we need a new micro-isolation route under cloud native conditions.

DaemonSet - the fourth route of micro-isolation

What is the most appropriate micro-isolation technology route in a cloud-native environment? The answer is DaemonSet.

What is a Daemonset?

DaemonSet is a type of Pod controller in Kubernetes, which can ensure that a copy of a Pod is run on all (or part of) Nodes. When a Node joins the cluster, DaemonSet will add a new Pod for it. When a Node is moved from the cluster When deleted, these Pods will also be recycled. The micro-isolation solution based on the DaemonSet form deploys the micro-isolation policy execution point in the container platform in the form of a guard container, so that it always runs on every Node.

Deployment diagram of Rose Smart Honeycomb adaptive micro-isolation security platform

Just like the "guardian" meaning in the word "Daemon", with the support of DaemonSet, micro-isolation capabilities can always stay "in step" with the elastic scaling of the container platform. So, what practical value can it bring to users who implement micro-isolation in a cloud-native environment?

First of all, this model has completely changed the original "plug-in grafting" installation based on Agent, and realized the native deployment of micro-isolation capabilities on the cloud platform in the form of "embedded fusion". The deployment of security capabilities is no longer agile and flexible. stumbling block", the technical dividends of cloud native can be fully released.

Secondly, when applications are expanded and new services are launched, managers no longer need to perform pre-operations such as Agent installation and initial configuration. They only need to maintain the guard container image on a daily basis. The automated operation and maintenance method greatly reduces management costs.

Of course, it has to be said that for most large users, the security, network, and operation and maintenance departments have a clear division of labor and each perform their own duties. Installing an Agent on a workload, a "trivial matter", often involves multiple departments, such as The operation and maintenance department will say "I can't give it root permissions!", and the business department will challenge "How much impact will the agent have on the business?", and these obstacles to the application of micro-isolation have completely disappeared with the arrival of the new model. .

This is the fourth way. Micro-isolation is neither caused byPAASWhat is provided by the platform itself is not provided by an independent firewall or agent, but becomesPAASAn independent business on the platform to DaemonSThe et method is managed uniformly by orchestration systems such as K8S, and is established and destroyed uniformly.

Rose Smart’s continuous innovation

Maybe it’s because there’s something thorny in the name, but Qiangwei’s smart path of micro-isolation has been walking among thorns. From a distance, micro-isolation is a prosperous and delicate thing, and there’s no one who can’t reach out without being pricked. Especially in a cloud-native environment, the vastly different network suites have brought great challenges to the implementation of micro-isolation. As the only stubborn company in China that does nothing but micro-isolation, Qiangwei has no other choice but to implement micro-isolation. We tried our best to meet the challenge. Fortunately, although it was a thorn in our side, we finally found a way out. Today we operate tens of thousands of cloud-native micro-isolation networks in China, which can be regarded as a contribution to domestic network security. own strength.

However, technological progress will never end. In the process of collaborative innovation with users, many users hope that we can do this in a more "cloud-native" way, which will make their operation and maintenance easier and installation easier. Deployment is easier and internal collaboration is more efficient.

User needs are our motivation, so we made a new version based on DaemonSet. From Agent to DaemonSet, there are still many difficulties. After the Agent obtains the permissions of the host, it is actually more convenient for it to do anything. However, once it is made into a DaemonSet, it is equivalent to being separated from the host by one layer. This layer brings significant obstacles to many necessary actions for us to perform micro-isolation.

I won’t say more, but it was quite laborious anyway. Fortunately, Qiangwei Smart’s engineers never did anything effortless along the way. They finally overcame a series of difficulties and successfully released a new version. Apply Let’s finish with a sentence for primary school composition——

"At the end of a hard day's work, Qiangwei Smart's engineer wiped the sweat from his forehead and looked at the ultra-large-scale cloud-native zero-trust network shining brightly in the sunset with a happy smile on his face."