Access control for inter-service network traffic and encryption in transit - Container Service for Kubernetes

Network security in ACK addresses two concerns: restricting which services can communicate, and encrypting the data they exchange. ACK provides Kubernetes network policies, VPC security groups, and traffic encryption through Service Mesh (ASM) and TLS to address both.

This page covers:

Traffic control

Network policies — restrict pod-to-pod and pod-to-external traffic
Security groups — manage traffic between cluster nodes and other VPC resources
Monitor and analyze traffic — identify abnormal traffic using VPC flow logs

Traffic encryption

Service Mesh (ASM) — mutual TLS between services
TLS for Ingress — HTTPS for externally exposed services

Network policies

By default, all pods in a Kubernetes cluster can communicate with each other. For production workloads, define network policies to control east-west traffic — the pod-to-pod traffic within and across namespaces.

Important

Only clusters using the Terway network plug-in support Kubernetes network policies. If your cluster has more than 100 nodes, the network policy proxy may increase load on the Kubernetes control plane. See Improve the performance of the NetworkPolicy feature for a large ACK cluster in Terway mode.

Network policies use pod selectors and labels to identify source and destination pods. Rules can also scope by IP address, port, and protocol.

For reference and visual tools, see:

Use network policies in ACK clusters
Kubernetes Network Policy Recipes
Network Policy Editor — create, visualize, and understand network policies interactively

Create a default deny-all policy

Apply the principle of least privilege to network policies, just as you would to role-based access control (RBAC). Start by denying all inbound and outbound traffic from a namespace, then add explicit allow rules for only the traffic you need.

The following policy denies all ingress and egress traffic in the default namespace:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny
  namespace: default
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  - Egress

To create a global deny policy across all namespaces, use Calico instead of a Kubernetes-native NetworkPolicy.

Allow DNS queries

After deploying a deny-all policy, pods lose the ability to resolve DNS. Add an egress rule that allows pods to reach CoreDNS on UDP port 53.

Label the kube-system namespace so the policy can reference it by selector:
```
kubectl label namespace kube-system name=kube-system
```

Apply the following network policy:

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 the full Kubernetes network policy specification, see Network Policies.

Allow traffic from specific pods

Use pod selectors to restrict which pods can reach a given service. Common use cases:

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

The following example creates an API server pod and a network policy that limits access to 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:

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 pods without the app=bookstore label are blocked:

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

Expected output:

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

Verify that pods with the app=bookstore label can connect:

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 intra-namespace rules

After opening communication between pods in a namespace, add targeted rules to restrict access between specific pods within that namespace. For examples and templates, see Kubernetes Network Policy Recipes.

Monitor and analyze traffic

Alibaba Cloud Virtual Private Cloud (VPC) flow logs record inbound and outbound traffic on elastic network interfaces (ENIs). Use flow logs to:

Verify access control list (ACL) rules
Monitor network traffic between resources, including pods
Troubleshoot network connectivity issues

For setup details, see Overview of flow logs.

Security group

When you create an ACK cluster, the system automatically creates a security group that allows communication among all nodes in the cluster. Security groups control traffic at the node level — between master nodes and worker nodes, between worker nodes and other VPC resources, and between worker nodes and external IP addresses.

To follow the principle of least privilege, add inbound and outbound rules to tighten the default security group. See Recommended inbound and outbound rules for the cluster security group.

For configuration guidance, see Configure security groups in different scenarios and Configure a security group.

When to use network policies vs security groups

	Network policies	Security groups
What it controls	Pod-to-pod and pod-to-external traffic (layer 3/4)	Node-to-node and node-to-VPC-resource traffic
Scope	Namespace and pod level	Cluster node level
Requirement	Terway network plug-in	All ACK clusters
Use when	Restricting east-west traffic between specific workloads	Controlling access between nodes and other cloud resources (databases, other VPC instances)

For layered security, use both: network policies to isolate workloads from each other, and security groups to control what nodes can reach outside the cluster.

Encrypt data transmission

Service Mesh (ASM)

Service Mesh (ASM) encrypts traffic between services using mutual Transport Layer Security (mTLS). Beyond authentication, ASM also supports:

Dynamic certificate loading via Envoy Secret Discovery Service (SDS), so service gateways support HTTPS
Traffic management 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 — enabling developers to identify and diagnose performance bottlenecks in distributed application architecture

For an overview of ASM, see What is ASM?. To configure HTTPS at the gateway level, see Use an ingress gateway to enable HTTPS.

To trace applications across ASM boundaries, see Use Managed Service for OpenTelemetry to trace applications inside and outside an ASM instance.

TLS for Ingress

Enable HTTPS for any service exposed through a Kubernetes Ingress. Use a Kubernetes Secret to store the TLS certificate and reference it in the Ingress resource. See Use a Secret to configure TLS to enable HTTPS access.

Container Service for Kubernetes:Network security