The access control of network traffic between services and traffic encryption during data transmission - Container Service for Kubernetes

Network security involves access control and traffic encryption. You can define network policies to limit network access between services to allow only specific traffic. Network policies consist of a variety of settings, such as the default allow or deny rules, namespace isolation, and security group settings. You can encrypt traffic during data transmission to prevent sensitive data tampering or breaches. By adopting the preceding technologies and solutions, you can enhance the security between services and protect the transmission of sensitive data.

Network policies

By default, pods can communicate with each other in a Kubernetes cluster. This poses security risks in production environments. You can create Kubernetes network policies 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 in ACK clusters 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.

Run the following command to add a label to a namespace:
```
kubectl label namespace kube-system name=kube-system
```

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 Network Policies.

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.

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

Create a YAML file based on the following template and run the kubectl apply -f command to deploy a network policy by using the YAML file.

The network policy 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

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
```

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. To enhance security, you can add inbound and outbound rules to the security group to implement the principle of least privilege. For more information, see Recommended inbound and outbound rules for the cluster security group.

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

Encrypt data transmission

Service Mesh (ASM)
ASM can encrypt data transmitted among services. In addition to mutual Transport Layer Security (mTLS) authentication, you can also use Envoy Secret Discovery Service (SDS) to enable service gateways to support HTTPS and dynamic certificate loading. You can use ASM with Application High Availability Service (AHAS) to manage traffic of applications that are deployed in Service Mesh instances. ASM is integrated with Tracing Analysis to provide capabilities for distributed application developers, such as trace mapping, service call counting, trace topology, and application dependency analysis. Developers can use these capabilities to identify and diagnose performance bottlenecks in a distributed application architecture and make development and diagnostics more efficient.
Use a Secret to configure TLS to enable HTTPS access
You must enable HTTPS access for services that are exposed by Ingresses in clusters. For more information, see Use a Secret to configure TLS to enable HTTPS access.