Configure ACK Network Policies and TLS Encryption for Zero-Trust Security - Container Service for Kubernetes

Network security in Container Service for Kubernetes (ACK) covers access control and traffic encryption. Use network policies to restrict traffic between services, and encrypt data in transit to prevent tampering or breaches.

Network policies vs. security groups

Network policies and security groups operate at different levels. Use them together for defense in depth.

Mechanism	Scope	Best for
Network policies	Pod-to-pod traffic (east-west traffic) and traffic between pods and external services	Restricting communication between microservices, namespaces, or specific pods
Security groups	Node-level and Virtual Private Cloud (VPC)-level traffic between nodes, other VPC resources, and external IP addresses	Controlling access to and from the cluster at the infrastructure layer

Use security groups to restrict infrastructure-level access and network policies to enforce fine-grained pod-level isolation within the cluster.

Restrict pod-to-pod traffic with network policies

By default, all pods in a Kubernetes cluster communicate with each other. This poses security risks in production. Network policies control traffic between pods (east-west traffic) and between pods and external services.

Network policies use pod selectors and labels to identify source and destination pods. Each policy can specify IP addresses, ports, protocols, or any combination of these.

When you use the Terway network plug-in, configure network policies for specific applications 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 network policy proxy may increase the load on the Kubernetes control plane. In this case, optimize your network policies. For more information, see Improve the performance of the NetworkPolicy feature for a large ACK cluster in Terway mode.

Recommended approach: default deny, then allow

Follow the principle of least privilege, similar to role-based access control (RBAC) policies. Start by denying all traffic, then add targeted rules to allow only what each workload needs.

Create a default deny policy -- Block all inbound and outbound traffic in the namespace.
Allow DNS queries -- Pods need DNS resolution to function.
Allow specific traffic -- Open only the paths each workload requires.

Step 1: Create a default deny policy

Create a network policy that denies all inbound and outbound traffic from a namespace. Alternatively, 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

Step 2: Allow DNS queries

After the default deny policy is in place, pods cannot resolve DNS names. Create a policy that allows all pods to send DNS queries to CoreDNS.

Add a label to the kube-system namespace:

   kubectl label namespace kube-system name=kube-system

Create a network policy that allows egress to CoreDNS on UDP port 53:

   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 controlling network traffic between pods with Kubernetes network policies, see Network Policies.

Step 3: Allow traffic from specific pods

After the default deny and DNS policies are in place, create policies that allow traffic only from authorized pods. Common use cases:

Allow only specific microservices to access an application.
Allow only specific applications to access a database.

The following example creates a pod and a network policy that allows ingress only from pods with the app: bookstore label.

Create a pod with the app=bookstore and role=api labels:

   kubectl run apiserver --image=nginx --labels="app=bookstore,role=api" --expose --port=80

Apply the following network policy. This policy allows ingress 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

Verify that access from pods without the app=bookstore label is denied: Expected output:

   kubectl run test-$RANDOM --rm -i -t --image=alpine -- sh

   / # wget -qO- --timeout=2 http://apiserver
   wget: download timed out

Verify that access from pods with the app=bookstore label is allowed: Expected output:

   kubectl run test-$RANDOM --rm -i -t --image=alpine --labels="app=bookstore,role=frontend" -- sh

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

Add custom rules between pods in a namespace

After creating a policy that allows communication between pods in a namespace, add custom rules to further limit communication between specific pods. For more information, see Kubernetes Network Policy Recipes.

Control node-level traffic with security groups

ACK uses security groups to manage traffic between master nodes and worker nodes. Security groups also 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 that allows communication among nodes within the cluster. To enforce the principle of least privilege, add inbound and outbound rules to the security group. 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.

Monitor and analyze traffic with flow logs

Alibaba Cloud VPC provides flow logs that record inbound and outbound traffic of elastic network interfaces (ENIs). Use flow logs to:

Verify access control list (ACL) rules
Monitor network traffic
Troubleshoot network issues
Identify abnormal traffic between resources (including pods) in a VPC

For more information, see Overview of flow logs.

Encrypt data in transit

Service Mesh (ASM)

Service Mesh (ASM) encrypts data transmitted between services. ASM supports:
- Mutual Transport Layer Security (mTLS) authentication between services
- Envoy Secret Discovery Service (SDS) for enabling HTTPS and dynamic certificate loading on service gateways
- Traffic management for applications deployed in Service Mesh instances, through integration with Application High Availability Service (AHAS)
- Distributed tracing through integration with Tracing Analysis, providing trace mapping, service call counting, trace topology, and application dependency analysis
TLS for Ingress

You must enable HTTPS access for services exposed by Ingresses in your cluster. Use a Kubernetes Secret to configure Transport Layer Security (TLS). For more information, see Use a Secret to configure TLS to enable HTTPS access.