All Products
Search
Document Center

Container Service for Kubernetes:Network security

Last Updated:Sep 07, 2023

This topic describes how to ensure network security by enforcing access control on services and encrypting data transmission.

Network policies

By default, pods can communicate with each other in a Kubernetes cluster. This poses security risks in production environments. Kubernetes network policies allow you to control traffic between pods and traffic between pods and external services. The traffic between pods refers to the east-west traffic. Network policies use pod selectors and labels to identify source pods and destination pods. In addition, you can specify IP addresses, ports, protocols, and a combination of them in network policies. When you use the Terway network plug-in, you can configure network policies for specific applications if you want to control network traffic at the IP address or port level. For more information, see Use network policies and Kubernetes Network Policy Recipes.

Important Only clusters that use the Terway network plug-in support Kubernetes network policies. If your cluster contains more than 100 nodes, the proxy of Kubernetes network policies may increase the loads of the Kubernetes control plane of your cluster. In this case, you need to optimize the Kubernetes network policies in your cluster. For more information, see Improve the performance of the NetworkPolicy feature for a large ACK cluster in Terway mode.

Create a default network policy that denies all traffic

Similar to role-based access control (RBAC) policies, you must follow the principle of least privilege when you create network policies. You can create a default network policy that denies all inbound and outbound traffic from a namespace. You can also create a global network policy by using Calico.
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny
  namespace: default
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  - Egress

Create a network policy that allows DNS queries

After you create the default network policy that denies all inbound and outbound traffic, you can create network policies for specific purposes. For example, you can create a global network policy that allows pods to send DNS queries to CoreDNS.

  1. Run the following command to add a label to a namespace:
    kubectl label namespace kube-system name=kube-system
  2. Create a network policy by using the following YAML template:
    apiVersion: networking.k8s.io/v1
    kind: NetworkPolicy
    metadata:
      name: allow-dns-access
      namespace: default
    spec:
      podSelector:
        matchLabels: {}
      policyTypes:
      - Egress
      egress:
      - to:
        - namespaceSelector:
            matchLabels:
              name: kube-system
        ports:
        - protocol: UDP
          port: 53
    Important For more information about how to control network traffic between pods by using Kubernetes network policies, see Official Documentation.

Allow traffic from specific pods

In the following scenarios, you can create a network policy to allow traffic from specific pods:

  • You want to allow only specific microservices to access an application.
  • You want to allow only specific applications to access a database.
  1. Run the following command to create a pod that has the app-bookstore and role=api labels.
    kubectl run apiserver --image=nginx --labels="app=bookstore,role=api" --expose --port=80
  2. Create a YAML file based on the following template and run the kubectl apply -f command to deploy a NetworkPolicy by using the YAML file.
    The NetworkPolicy allows traffic only from pods that have the app-bookstore label.
    kind: NetworkPolicy
    apiVersion: networking.k8s.io/v1
    metadata:
      name: api-allow
    spec:
      podSelector:
        matchLabels:
          app: bookstore
          role: api
      ingress:
      - from:
          - podSelector:
              matchLabels:
                app: bookstore
  3. Run the following command to check whether access from pods that do not have the app-bookstore label is denied:
    kubectl run test-$RANDOM --rm -i -t --image=alpine -- sh

    Expected output:

    / # wget -qO- --timeout=2 http://apiserver
    wget: download timed out
  4. Run the following command to check whether access from pods that have the app-bookstore label is allowed:
    kubectl run test-$RANDOM --rm -i -t --image=alpine --labels="app=bookstore,role=frontend" -- sh

    Expected output:

    / # wget -qO- --timeout=2 http://apiserver
    <!DOCTYPE html>
    <html><head>

Add custom rules to allow traffic between specific pods in a namespace

After you create a network policy that allows communication between pods in a namespace, you can add custom rules to limit communication between specific pods in the namespace. For more information, see Kubernetes Network Policy Recipes.

Monitor and analyze traffic data

Alibaba Cloud Virtual Private Cloud (VPC) provides flow logs that record information about inbound and outbound traffic of elastic network interfaces (ENIs). Flow logs help verify access control list (ACL) rules, monitor network traffic, and troubleshoot network issues. You can identify abnormal traffic between resources (including pods) in a VPC by analyzing flow logs. For more information, see Overview of flow logs.

Security group

ACK uses security groups to manage traffic between master nodes and worker nodes. You can also use security groups to manage traffic between worker nodes, other VPC resources, and external IP addresses. When you create an ACK cluster, the system automatically creates a security group for the cluster. The security group allows communication among nodes within the cluster. You can add inbound and outbound rules to the security group based on the settings in the following table to enforce the principle of least privilege.

Rule typeProtocolPort rangeSourceDestination
Inbound rule for least privilege (from the control plane and other nodes)TCP or protocols that you want to use for communication between nodes443, 10250, or ports that you want to use for communication between nodesCluster security groupN/A
Recommended inbound ruleALL/TCPALL/443, 1025-65535Cluster security groupN/A
Outbound rule for least privilegeTCP443N/ACluster security group
Recommended outbound ruleALLALLN/A0.0.0.0/0

For more information, see Configure security groups in different scenarios and Configure a security group.