Configuring a Network Defense Policy (for a Cluster Using the Container Tunnel Network Model)

The synchronization takes about 1 to 2 minutes. Wait for a while and click in the upper right corner of the list to refresh and view the latest data.

Figure 1 Synchronizing CCE Cluster policies

An example of a network policy created from YAML is as follows:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: test-network-policy
  namespace: default
spec:
  podSelector:                  # The rule takes effect for pods with the role=db label.
    matchLabels:
      role: db
  policyTypes:
    - Ingress
    - Egress
  ingress:                      # Ingress rule
    - from:
        - namespaceSelector: # Only namespaces with project=myproject can be accessed.
            matchLabels:
              project: myproject
        - podSelector:              # Only the traffic from the pods with the role=frontend label is allowed.
            matchLabels:
              role: frontend
      ports                       # Only TCP can be used to access port 6379.
        - protocol: TCP
          port: 6379
  egress:                         # Egress rule
    - to:
        - ipBlock:                #Only the 10.0.0.0/24 network segment of the destination object can be accessed.
            cidr: 10.0.0.0/24
      ports:                      # Only TCP can be used to access port 6379 of the destination object.
        - protocol: TCP
          port: 6379

The synchronization takes about 1 to 2 minutes. Wait for a while and click in the upper right corner of the list to refresh and view the latest data.

Figure 2 Synchronizing CCE Cluster policies

• Policy Name: Enter a network policy name.
• Namespace: Select a namespace for the network policy.
• Selector: Enter a key and a value to set the pod to be associated, and click Add. You can also click Reference Workload Label to reference the label of an existing workload. If this parameter is not specified, all pods in the namespace are associated by default.
• Inbound rule: Click Add Rule in the Inbound Rules area. For more information, see Table 1.

  Table 1 Adding an inbound rule

  Parameter	Description
  Protocol & Port	Enter the inbound protocol type and port number of the pods to be associated. Currently, TCP and UDP are supported. If this parameter is not specified, all access traffic is allowed.
  Source Namespace	Select a namespace whose objects can be accessed. If this parameter is not specified, access to the objects that belong to the same namespace as the current policy is allowed.
  Source Pod Label	Select a label. Pods with this label can be accessed. If this parameter is not specified, all pods in the namespace can be accessed.

• Outbound rule: Click Add Rule in the Outbound Rules area. For more information, see Table 2.

  Table 2 Adding an outbound rule

  Parameter	Description
  Protocol & Port	Enter the port and protocol of destination objects. If this parameter is not specified, access is not limited.
  Destination CIDR Block	Configure CIDR blocks. This parameter allows requests to be routed to a specified CIDR block (and not to the exception CIDR blocks). Separate the destination and exception CIDR blocks by vertical bars (|), and separate multiple exception CIDR blocks by commas (,). For example, 172.17.0.0/16|172.17.1.0/24,172.17.2.0/24 indicates that 172.17.0.0/16 is accessible, but not for 172.17.1.0/24 or 172.17.2.0/24.
  Destination Namespace	Namespace where the destination object is located. If not specified, the object belongs to the same namespace as the current policy.
  Destination Pod Label	Select a label. Pods with this label can be accessed. If this parameter is not specified, all pods in the namespace can be accessed.