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

How to use Kubernetes network strategy for application micro-segmentation, for this problem, this article introduces the corresponding analysis and solution in detail, hoping to help more partners who want to solve this problem to find a more simple and feasible method.

In most production environments, network access control needs to be implemented. Kubernetes provides a way to describe how Pod groups should communicate by using NetworkPolicy resources. As with most things in Kubernetes, for network policies to work, you need a Kubernetes CNI plug-in that supports them.

Working with scen

In almost all environments, it is a good idea to establish clear rules for the components that the application needs to communicate. The Kubernetes network policy specification is a direct approach that allows you to integrate NetworkPolicy directly with the application manifest. The way NetworkPolicy defines resources allows you to specify exactly which network traffic is allowed and which is not, while using podSelector definitions to handle the dynamic properties of applications running on Kubernetes. This means that your policy can target a single Pod or Pod group, thus "narrowing" the security scope to the size of the Pod. The combination of strictly defined network policies and default-deny configuration can avoid the trouble caused by malicious application intrusion, and / or misbehavior, or misconfiguration. For example, an application component may have stranded cache DNS entries or incorrect configuration parameters, causing it to communicate with the wrong backend. Or the application may be compromised and used as a springboard to perform reconnaissance, attempt horizontal penetration, or simply use Pod's access to Kubernetes API to start some cryptocurrency mining Pod to steal your computing resources.

Use network policies to secure the sample application

The topic of network policy design is much larger than the space allowed in this guide. In this example, we will do the following:

Create a default-deny Ingress policy for our default namespace. This means that all incoming Pods connections within the namespace must be explicitly allowed

Create an Ingress NetworkPolicy object for each sample application component, allowing only those objects that we have identified.

Step 1: identify which components should be able to communicate with each other

First, we need to remind ourselves of how the various components of the application should communicate. To do this, we will return to the application diagram we saw in the introduction:

From this picture, we can see: 1. The outside world needs to reach TCP ports 80-(1) and (2) 2 of yelb-ui. Yelb-ui needs to reach TCP port 45673 of yelb-appserver. Yelb-appserver, in turn, will need to reach TCP port 5432 of yelb-db, and 4. TCP port 6379 for yelb-cache.

Step 2: how to identify components?

Keep in mind that NetworkPolicy resources use selectors to identify which Pod the policy applies to and what is the source and destination of the traffic that the policy will control. In this demonstration, we will use the podSelectror method, so we need to get a list of tags applied to the application Pod. Let's look at the listing of the cnawebapp-loadbalancer.yaml sample application and collect the tags:

Now we are ready to write our strategy.

When deployed, these policies control communication between application components in the following ways:

Step 3: "default-deny" strategy

Make sure you are on the sandbox control node, logged in as root, and in the correct directory: # confirm that you are the root account whoami | grep root | | sudo-s

# switch to inventory directory

Cd / home/centos/yelb/deployments/platformdeployment/Kubernetes/yaml

In this step, we will create a policy that will block all network traffic that is not explicitly allowed. In this demonstration, we will limit only Ingress traffic; but in fact, you can also control Egress traffic (but be aware that this may block DNS queries! ):

The policy basically says, "for any Pod, apply an irregular Ingress policy," which causes all incoming traffic to this namespace Pods to be discarded.

Step 4: strategy for "yelb-ui"

This yelb-ui is somewhat different from other components in a sense because it is the only component that can be accessed externally. Therefore, its ingress: definition will use ipBlock's 0.0.0.0 ipBlock 0 to represent "everyone":

The policy says: "for Pods with application tags app: yelb-ui and tier: frontend, traffic from any source IP is allowed, as long as it goes to TCP port 80 of Pod."

Step 5: policies for other Pod in the sample application

The other three Pod in our sample application will only see traffic from other Pod, so its policy will use the podSelector parameter with a Pod tag that allows traffic to be sent:

Step 6: test before applying the policy

In order to have a "front-to-back" comparison, let's deploy the sample application and get the baseline:

# deploy our application

Kubectl create-f cnawebapp-loadbalancer.yaml

Wait for the application to launch and be available externally: # get the external DNS name of our program yelb-ui Service: kubectl get svc-o wide | grep yelb-ui | awk'{print $4}'

We should see output similar to a0b8dfc14916811e9b411026463a4a33-1258487840.us-west-1.elb.amazonaws.com; open it in a web browser; the sample application should be loaded.

Next, we know that all Pod communication is unrestricted, so we should be able to go from yelb-ui ping to yelb-db--, which is an activity that should not have happened if the application was running normally and we did not take troubleshooting action:

# get the full Pod name of "yelb-ui"

Src_pod=$ (kubectl get pods | grep yelb-ui | awk'{print $1}')

# obtain the IP of "yelb-db":

Db_pod_ip=$ (kubectl get pods-o wide | grep yelb-db | awk'{print $6}')

# from "yelb-ui" ping "yelb-db":

Kubectl exec-it ${src_pod} ping ${db_pod_ip}

We should see that the ping command is receiving a response; therefore there is an unrestricted network connection. Press ^ C to stop the command.

Step 7: deploy the strategy and test the results

In the final step, we will deploy the policy and observe its effect: # deploy the network policy

Kubectl create-f yelb-policy.yaml

After running the above command, wait a few seconds to stabilize. Tungsten Fabric will generate the appropriate security group in the background and install it. Let's test whether the ping command that we used to run normally is still valid: # from "yelb-ui" ping "yelb-db" again:

Kubectl exec-it ${src_pod} ping ${db_pod_ip}

This time, we see no response because the communication is now blocked by the policy. Next, test whether the application can still be accessed through a web browser-it should be!

Step 8: explore the visualization of secure traffic groups for Tungsten Fabric

Tungsten Fabric includes a feature that enables traffic visualization in the Project, which in our case corresponds to Kubernetes Namespace. To access it, visit the Carbide Evaluation Page link to get access to the sandbox control node-- there is a link called Contrail UI at the top to complete the input of login and password. Click the link, then click the "Monitor" icon in the upper left corner, and then click "Security"-> "Traffic Groups" in the menu. Then at the top of the label chain, select "k8s-default" at the end of it:

You should see a chart similar to the following:

Keep testing. The flow you see represents what the sample application is doing, including unable to go from yelb-uiping to yelb-db, and outbound requests from yelb-appserver (if we look at it, we will go to yelb-db 's DNS query).

Clear

Once you have done enough exploration, you can clean up at any time: # Uninstall Network Policy

Kubectl delete-f yelb-policy.yaml

# Delete our sample application:

Kubectl delete-f cnawebapp-loadbalancer.yaml

# deletion policy list: rm-f yelb-policy.yaml

Review and resourc

For many, if not all, production deployments, controlling the network communication capabilities of applications is critical. Applications running on Kubernetes implement such controls through NetwokPolicy resources. However, for these resources to really work, you need a CNI plug-in that supports them. Tungsten Fabric provides full NetworkPolicy support, no matter where the Tungsten Fabric-integrated Kubernetes runs, in a private data center or in a public cloud. Network policies can become very simple or very complex, and finding the best way to work best for your application is to delve deeper into the use cases and examples we provide. This is the answer to the question on how to segment the application through the Kubernetes network strategy. I hope the above content can be of some help to you. If you still have a lot of doubts to be solved, you can follow the industry information channel for more related knowledge.

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.