Network Security Internet Technology Development Database Servers Mobile Phone Android Software Apple Software Computer Software News IT Information

In addition to Weibo, there is also WeChat

Please pay attention

WeChat public account

Shulou

Tungsten Fabric and K8s Integration Guide: creating Security Policy

2025-04-02 Update From: SLTechnology News&Howtos shulou NAV: SLTechnology News&Howtos > Network Security >

Share

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

Author: Wu Mingmi

Hi! Welcome to the Tungsten Fabric and Kubernetes Integration Guide series, which describes how to create a security policy. The Tungsten Fabric and K8s integration guide series, presented by the TF Chinese community, is designed to help you understand the basics of Tungsten Fabric and K8s integration. If you have any experience or problems in the relevant deployment, please feel free to contact us.

Security policy can control the access between any pod and the access between pod and service by restricting ports, network protocols, and so on. In K8s cluster, the security policy corresponds to Network Policy, and in Tungsten Fabric, the security policy corresponds to Firewall Rule, and the two are synchronized in real time.

Access control between pod

The control of a security policy is global, across namespaces and across network, so when creating a policy, specify some parameters from end to end, including port, namespace, IP address field, and so on, in as much detail as possible.

According to the information in the second chapter, we can know that there is at present--

Two namespaces: test-ns1 test-ns2

Three network:k8s-ns1-pod-net01 k8s-ns1-pod-net02 k8s-ns2-pod-net01

Four pod:

Nginx01-ns1-net01

Nginx01-ns1-net02

Nginx01-ns2-net01

Nginx02-ns2-net01

K8s-ns1-pod-net01 and k8s-ns1-pod-net02 have been interconnected (through the new TF router connection), and k8s-ns1-pod-net01 and k8s-ns2-pod-net01 have been interconnected (connected through TF Network Policy).

First, add a default no-access policy that forbids any traffic from accessing test-ns1 's pod, configured as follows:

The # pod selector is set to empty, which means that all pod are selected, that is, the entire namespace is controlled.

# only write ingress to take effect, and set podSelector to empty, which denies access to other namespaces and rejects all inbound requests.

# No egress is added, so the default egress is to allow all pod outbound in this namespace.

After creating the policy, verify that the k8s-ns2-pod-net01 network of test-ns1 can be accessed from test-ns1 's k8s-ns1-pod-net01 network from test-ns1 's k8s-ns2-pod-net01 network.

The verification process is shown in the following figure. It is possible to go from pod of test-ns2 to pod of ping test-ns1, but after creating Network Policy, ping cannot be connected, indicating that Network Policy restricts traffic from other places to access the pod of test-ns1, and even pod within test-ns1 cannot access each other.

On the management interface of Tungsten Fabric, you will see a new Firewall Rule:

Then, a new security policy is added to allow pod in subnet 20.10.10.10.Maple 24 to access port 80 of pod labeled nginx-ns1 in test-ns1 (both pod in test-ns1 have this label), except for pod with IP of 20.10.10.3, as follows:

After creating the policy, verify that port 80 of test-ns1 's pod can be accessed from the pod of test-ns2.

The verification process is shown in the following figure. First, curl is used to request port 80 of test-ns1 pod (10.10.10.1) from two pod of test-ns2 (20.10.10.1 and 20.10.10.3). Before a new security policy is created, the curl request fails.

After the security policy is created, only pod (20.10.10.1) can successfully request pod (10.10.10.1), while pod (20.10.10.3) cannot successfully request the corresponding port 80, indicating that the new policy is in effect normally.

Three new Firewall Rule have been created on Tungsten Fabric. They are:

The pod that allows the network segment 10.10.0 pod 24 asks the pod; with the label app=nginx-ns1 in the test-ns1 to prohibit the pod with the label ip 10.10.3 32 from accessing the pod; with the label app=nginx-ns1 in the test-ns1. All pod is prohibited from accessing the pod with the label app=nginx-ns1 in the test-ns1.

After the combination of the three rules, we can achieve the desired pod isolation effect.

Access Control between pod and service

Service of K8s is an abstract concept, which defines multiple pod logical sets of a service and the policy of accessing pod. Service is generally referred to as micro-service.

Here, first, create a new service in both test-ns1 and test-ns2, with the following configuration:

Execute the kubectl creation command, and the two service are created in test-ns1 and test-ns2, respectively, and the corresponding load balancing list in Tungsten Fabric will also generate information about the two service.

Through test-ns1 's pod (10.10.10.1), you can use curl to directly request the domain name of service.

Now disable test-ns1 's pod (10.10.10.1) from accessing test-ns2 's service (nginx-ns2) by creating a new Network Policy for K8s.

Prohibit test-ns1 's pod (10.10.10.1) from requesting ClusterIP (10.96.0.12) of test-ns2 's service (nginx-ns2). The specific configuration is as follows:

Verification process:

Pod (10.10.1) of 1.test-ns1 can successfully request service (nginx-ns2) of test-ns2 through curl and service (kube-dns) of kube-system through nslookup before creating network policy kube-dns.

Create a network policy deny-service-ip for K8s in the test-ns1 namespace

3.test-ns1 's pod (10.10.1) cannot successfully request test-ns2 's service (nginx-ns2) through curl after creating the test-ns2 network policy, but can successfully request kube-system 's service (kube-dns) through nslookup.

So the network policy deny-service-ip does prohibit test-ns1 's pod (10.10.10.1) without affecting its access to other service clusterip.

(the writer is from Shenzhen Tianyuan Jingyun Technology Co., Ltd.)

"Tungsten Fabric+K8s Integration Guide" series of articles--

Part 1: deployment preparation and initial state

Part 2: creating a Virtual Network

"Tungsten Fabric+K8s easy to use" series of articles

Part I: TF Carbide Evaluation Guide-preparation

Part 2: basic application connections through Kubernetes services

Part 3: advanced external application connections through Kubernetes Ingress

Part IV: preliminary application isolation through Kubernetes namespaces

Part V: application differential Segmentation through Kubernetes Network Strategy

Follow Wechat: TF Chinese Community

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.

Views: 262

*The comments in the above article only represent the author's personal views and do not represent the views and positions of this website. If you have more insights, please feel free to contribute and share.

Share To

Network Security

Wechat

© 2024 shulou.com SLNews company. All rights reserved.

12
Report