在 Azure Kubernetes Service (AKS) 中使用網路原則來保護 Pod 之間的流量Secure traffic between pods using network policies in Azure Kubernetes Service (AKS)

• 05/06/2019
• • 

當您在 Kubernetes 中執行新式微服務架構的應用程式時，您通常想要控制哪些元件可以彼此通訊。When you run modern, microservices-based applications in Kubernetes, you often want to control which components can communicate with each other. 最小許可權的原則應套用到流量可以如何在 Azure Kubernetes Service (AKS) 叢集中的 pod 之間流動。The principle of least privilege should be applied to how traffic can flow between pods in an Azure Kubernetes Service (AKS) cluster. 假設您可能想要封鎖直接傳送至後端應用程式的流量。Let's say you likely want to block traffic directly to back-end applications. Kubernetes 中的網路原則功能可讓您定義叢集中 pod 之間的輸入和輸出流量規則。The Network Policy feature in Kubernetes lets you define rules for ingress and egress traffic between pods in a cluster.

本文說明如何安裝網路原則引擎並建立 Kubernetes 網路原則, 以控制 AKS 中 pod 之間的流量。This article shows you how to install the network policy engine and create Kubernetes network policies to control the flow of traffic between pods in AKS. 網路原則只應用於 AKS 中以 Linux 為基礎的節點和 pod。Network policy should only be used for Linux-based nodes and pods in AKS.

開始之前Before you begin

您需要安裝並設定 Azure CLI 版本2.0.61 或更新版本。You need the Azure CLI version 2.0.61 or later installed and configured. 執行  az --version 以尋找版本。Run az --version to find the version. 如果您需要安裝或升級, 請參閱 安裝 Azure CLI。If you need to install or upgrade, see Install Azure CLI.

網路原則概觀Overview of network policy

根據預設, AKS 叢集中的所有 pod 都可以不受限制地傳送和接收流量。All pods in an AKS cluster can send and receive traffic without limitations, by default. 為了提升安全性，您可以定義可控制流量流程的規則。To improve security, you can define rules that control the flow of traffic. 例如, 後端應用程式通常只會對必要的前端服務公開。Back-end applications are often only exposed to required front-end services, for example. 或者, 只有連接到資料庫元件的應用層能夠存取它們。Or, database components are only accessible to the application tiers that connect to them.

網路原則是一種 Kubernetes 規格, 可定義 pod 之間通訊的存取原則。Network Policy is a Kubernetes specification that defines access policies for communication between Pods. 使用網路原則時, 您可以定義一組已排序的規則來傳送和接收流量, 並將其套用至符合一或多個標籤選取器的 pod 集合。Using Network Policies, you define an ordered set of rules to send and receive traffic and apply them to a collection of pods that match one or more label selectors.

這些網路原則規則會定義為 YAML 資訊清單。These network policy rules are defined as YAML manifests. 網路原則可以包含在更廣泛的資訊清單中, 也會建立部署或服務。Network policies can be included as part of a wider manifest that also creates a deployment or service.

AKS 中的網路原則選項Network policy options in AKS

Azure 提供兩種方式來執行網路原則。Azure provides two ways to implement network policy. 當您建立 AKS 叢集時, 可以選擇網路原則選項。You choose a network policy option when you create an AKS cluster. 建立叢集之後, 就無法變更原則選項:The policy option can't be changed after the cluster is created:

• Azure 本身的實作為, 稱為「 Azure 網路原則」。Azure’s own implementation, called Azure Network Policies.
• Calico 網路原則, 這是由Tigera所成立的開放原始碼網路和網路安全性解決方案。Calico Network Policies, an open-source network and network security solution founded by Tigera.

這兩個部署都使用 Linux IPTables來強制執行指定的原則。Both implementations use Linux IPTables to enforce the specified policies. 原則會轉譯成一組允許和不允許的 IP 配對。Policies are translated into sets of allowed and disallowed IP pairs. 這些配對接著會做為 IPTable 篩選規則的程式設計。These pairs are then programmed as IPTable filter rules.

網路原則僅適用于 Azure CNI (advanced) 選項。Network policy only works with the Azure CNI (advanced) option. 這兩個選項的執行方式不同:Implementation is different for the two options:

• Azure 網路原則-azure CNI 會在 VM 主機中設定用於節點內部網路的橋接器。Azure Network Policies - the Azure CNI sets up a bridge in the VM host for intra-node networking. 當封包通過橋接器時, 會套用篩選規則。The filtering rules are applied when the packets pass through the bridge.
• Calico 網路原則-Azure CNI 會為內部節點流量設定本機核心路由。Calico Network Policies - the Azure CNI sets up local kernel routes for the intra-node traffic. 這些原則會套用在 pod 的網路介面上。The policies are applied on the pod’s network interface.

Azure 與 Calico 原則之間的差異及其功能Differences between Azure and Calico policies and their capabilities

建立 AKS 叢集並啟用網路原則Create an AKS cluster and enable network policy

若要查看作用中的網路原則, 讓我們先建立並展開定義流量的原則:To see network policies in action, let's create and then expand on a policy that defines traffic flow:

• 拒絕流向 Pod 的所有流量。Deny all traffic to pod.
• 允許以 Pod 標籤為基礎的流量。Allow traffic based on pod labels.
• 允許以命名空間為基礎的流量。Allow traffic based on namespace.

首先, 讓我們建立支援網路原則的 AKS 叢集。First, let's create an AKS cluster that supports network policy. 只有在建立叢集時, 才可以啟用網路原則功能。The network policy feature can only be enabled when the cluster is created. 您無法在現有的 AKS 叢集上啟用網路原則。You can't enable network policy on an existing AKS cluster.

若要使用網路原則搭配 AKS 叢集, 您必須使用AZURE CNI 外掛程式, 並定義您自己的虛擬網路和子網。To use network policy with an AKS cluster, you must use the Azure CNI plug-in and define your own virtual network and subnets. 如需如何規劃必要子網範圍的詳細資訊, 請參閱設定 advanced 網路。For more detailed information on how to plan out the required subnet ranges, see configure advanced networking.

下列範例指令碼：The following example script:

• 建立虛擬網路和子網路。Creates a virtual network and subnet.
• 建立與 AKS 叢集搭配使用的 Azure Active Directory (Azure AD) 服務主體。Creates an Azure Active Directory (Azure AD) service principal for use with the AKS cluster.
• 針對虛擬網路上的 AKS 叢集服務主體指派「參與者」權限。Assigns Contributor permissions for the AKS cluster service principal on the virtual network.
• 在定義的虛擬網路中建立 AKS 叢集, 並啟用網路原則。Creates an AKS cluster in the defined virtual network and enables network policy.
  • 使用 [ azure網路原則] 選項。The azure network policy option is used. 若要改為使用 Calico 做為網路原則選項, --network-policy calico請使用參數。To use Calico as the network policy option instead, use the --network-policy calico parameter.

提供您自己的安全 SP_PASSWORD。Provide your own secure SP_PASSWORD. 您可以取代RESOURCE_GROUP_NAME和CLUSTER_NAME變數:You can replace the RESOURCE_GROUP_NAME and CLUSTER_NAME variables:

RESOURCE_GROUP_NAME=myResourceGroup-NP
CLUSTER_NAME=myAKSCluster
LOCATION=canadaeast

# Create a resource group
az group create --name $RESOURCE_GROUP_NAME --location $LOCATION

# Create a virtual network and subnet
az network vnet create \
    --resource-group $RESOURCE_GROUP_NAME \
    --name myVnet \
    --address-prefixes 10.0.0.0/8 \
    --subnet-name myAKSSubnet \
    --subnet-prefix 10.240.0.0/16

# Create a service principal and read in the application ID
SP=$(az ad sp create-for-rbac --output json)
SP_ID=$(echo $SP | jq -r .appId)
SP_PASSWORD=$(echo $SP | jq -r .password)

# Wait 15 seconds to make sure that service principal has propagated
echo "Waiting for service principal to propagate..."
sleep 15

# Get the virtual network resource ID
VNET_ID=$(az network vnet show --resource-group $RESOURCE_GROUP_NAME --name myVnet --query id -o tsv)

# Assign the service principal Contributor permissions to the virtual network resource
az role assignment create --assignee $SP_ID --scope $VNET_ID --role Contributor

# Get the virtual network subnet resource ID
SUBNET_ID=$(az network vnet subnet show --resource-group $RESOURCE_GROUP_NAME --vnet-name myVnet --name myAKSSubnet --query id -o tsv)

# Create the AKS cluster and specify the virtual network and service principal information
# Enable network policy by using the `--network-policy` parameter
az aks create \
    --resource-group $RESOURCE_GROUP_NAME \
    --name $CLUSTER_NAME \
    --node-count 1 \
    --generate-ssh-keys \
    --network-plugin azure \
    --service-cidr 10.0.0.0/16 \
    --dns-service-ip 10.0.0.10 \
    --docker-bridge-address 172.17.0.1/16 \
    --vnet-subnet-id $SUBNET_ID \
    --service-principal $SP_ID \
    --client-secret $SP_PASSWORD \
    --network-policy azure

建立叢集需要幾分鐘的時間。It takes a few minutes to create the cluster. 當叢集準備就緒時, 請kubectl使用az aks get-認證命令來設定以連線到您的 Kubernetes 叢集。When the cluster is ready, configure kubectl to connect to your Kubernetes cluster by using the az aks get-credentials command. 此命令會下載憑證並設定 Kubernetes CLI 以供使用：This command downloads credentials and configures the Kubernetes CLI to use them:

az aks get-credentials --resource-group $RESOURCE_GROUP_NAME --name $CLUSTER_NAME

拒絕流向 Pod 的所有輸入流量Deny all inbound traffic to a pod

在您定義規則以允許特定網路流量之前，先建立網路原則以拒絕所有流量。Before you define rules to allow specific network traffic, first create a network policy to deny all traffic. 此原則可讓您開始只將所需的流量列入允許清單。This policy gives you a starting point to begin to whitelist only the desired traffic. 您可以也清楚地看到套用網路原則時會捨棄該流量。You can also clearly see that traffic is dropped when the network policy is applied.

針對範例應用程式環境和流量規則, 讓我們先建立名為「開發」的命名空間, 以執行範例 pod:For the sample application environment and traffic rules, let's first create a namespace called development to run the example pods:

kubectl create namespace development
kubectl label namespace/development purpose=development

建立執行 NGINX 的範例後端 pod。Create an example back-end pod that runs NGINX. 這個後端 pod 可以用來模擬範例後端 web 應用程式。This back-end pod can be used to simulate a sample back-end web-based application. 在 development 命名空間中建立這個 Pod，然後開啟連接埠 80 來處理 Web 流量。Create this pod in the development namespace, and open port 80 to serve web traffic. 替 Pod 加上 app=webapp,role=backend 標籤，以便我們在下一節中使用網路原則以其作為目標：Label the pod with app=webapp,role=backend so that we can target it with a network policy in the next section:

kubectl run backend --image=nginx --labels app=webapp,role=backend --namespace development --expose --port 80 --generator=run-pod/v1

建立另一個 pod, 然後連結終端機會話, 以測試您可以成功連線到預設的 NGINX 網頁:Create another pod and attach a terminal session to test that you can successfully reach the default NGINX webpage:

kubectl run --rm -it --image=alpine network-policy --namespace development --generator=run-pod/v1

在 shell 提示字元中, wget使用來確認您可以存取預設的 NGINX 網頁:At the shell prompt, use wget to confirm that you can access the default NGINX webpage:

wget -qO- http://backend

下列範例輸出顯示傳回的預設 NGINX 網頁:The following sample output shows that the default NGINX webpage returned:

<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
[...]

結束連結的終端機工作階段。Exit out of the attached terminal session. 測試 pod 會自動刪除。The test pod is automatically deleted.

exit

建立並套用網路原則Create and apply a network policy

既然您已確認可以在範例後端 pod 上使用基本 NGINX 網頁, 請建立網路原則來拒絕所有流量。Now that you've confirmed you can use the basic NGINX webpage on the sample back-end pod, create a network policy to deny all traffic. 建立名為 backend-policy.yaml 的檔案，並貼上下列 YAML 資訊清單。Create a file named backend-policy.yaml and paste the following YAML manifest. 此資訊清單會使用podSelector將原則附加至具有app: webapp、role: 後端標籤的 pod, 如同您的範例 NGINX pod。This manifest uses a podSelector to attach the policy to pods that have the app:webapp,role:backend label, like your sample NGINX pod. ingress 之下未定義任何規則，因此會拒絕流向 Pod 的所有輸入流量：No rules are defined under ingress, so all inbound traffic to the pod is denied:

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: backend-policy
  namespace: development
spec:
  podSelector:
    matchLabels:
      app: webapp
      role: backend
  ingress: []

使用kubectl apply命令來套用網路原則, 並指定 YAML 資訊清單的名稱:Apply the network policy by using the kubectl apply command and specify the name of your YAML manifest:

kubectl apply -f backend-policy.yaml

測試網路原則Test the network policy

讓我們看看您是否可以再次在後端 pod 上使用 NGINX 網頁。Let's see if you can use the NGINX webpage on the back-end pod again. 建立另一個測試 Pod 並連結終端機工作階段：Create another test pod and attach a terminal session:

kubectl run --rm -it --image=alpine network-policy --namespace development --generator=run-pod/v1

在 shell 提示字元中, wget使用來查看您是否可以存取預設的 NGINX 網頁。At the shell prompt, use wget to see if you can access the default NGINX webpage. 此時，將逾時值設定為 2 秒。This time, set a timeout value to 2 seconds. 網路原則現在會封鎖所有輸入流量, 因此無法載入頁面, 如下列範例所示:The network policy now blocks all inbound traffic, so the page can't be loaded, as shown in the following example:

$ wget -qO- --timeout=2 http://backend

wget: download timed out

結束連結的終端機工作階段。Exit out of the attached terminal session. 測試 pod 會自動刪除。The test pod is automatically deleted.

exit

允許以 Pod 標籤為基礎的輸入流量Allow inbound traffic based on a pod label

在上一節中, 已排程後端 NGINX pod, 並已建立網路原則來拒絕所有流量。In the previous section, a back-end NGINX pod was scheduled, and a network policy was created to deny all traffic. 讓我們建立前端 pod 並更新網路原則, 以允許來自前端 pod 的流量。Let's create a front-end pod and update the network policy to allow traffic from front-end pods.

更新網路原則，以允許來自任何命名空間中具有 app:webapp,role:frontend 標籤的 Pod 流量。Update the network policy to allow traffic from pods with the labels app:webapp,role:frontend and in any namespace. 編輯先前的後端原則 yaml檔案, 並新增matchLabels輸入規則, 讓您的資訊清單看起來如下列範例所示:Edit the previous backend-policy.yaml file, and add matchLabels ingress rules so that your manifest looks like the following example:

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: backend-policy
  namespace: development
spec:
  podSelector:
    matchLabels:
      app: webapp
      role: backend
  ingress:
  - from:
    - namespaceSelector: {}
      podSelector:
        matchLabels:
          app: webapp
          role: frontend

使用kubectl apply命令來套用已更新的網路原則, 並指定 YAML 資訊清單的名稱:Apply the updated network policy by using the kubectl apply command and specify the name of your YAML manifest:

kubectl apply -f backend-policy.yaml

將標示為app = webapp, role = 前端的 pod 排程, 並連結終端機會話:Schedule a pod that is labeled as app=webapp,role=frontend and attach a terminal session:

kubectl run --rm -it frontend --image=alpine --labels app=webapp,role=frontend --namespace development --generator=run-pod/v1

在 shell 提示字元中, wget使用來查看您是否可以存取預設的 NGINX 網頁:At the shell prompt, use wget to see if you can access the default NGINX webpage:

wget -qO- http://backend

因為輸入規則允許具有「應用程式: webapp, role: 前端」標籤的 pod 流量, 所以允許來自前端 pod 的流量。Because the ingress rule allows traffic with pods that have the labels app: webapp,role: frontend, the traffic from the front-end pod is allowed. 下列範例輸出會顯示傳回的預設 NGINX 網頁:The following example output shows the default NGINX webpage returned:

<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
[...]

結束連結的終端機工作階段。Exit out of the attached terminal session. Pod 會自動刪除。The pod is automatically deleted.

exit

測試沒有相符標籤的 PodTest a pod without a matching label

網路原則允許來自標籤為 app: webapp,role: frontend 的 Pod 流量，但應該拒絕所有其他流量。The network policy allows traffic from pods labeled app: webapp,role: frontend, but should deny all other traffic. 讓我們進行測試, 以查看沒有這些標籤的另一個 pod 是否可以存取後端 NGINX pod。Let's test to see whether another pod without those labels can access the back-end NGINX pod. 建立另一個測試 Pod 並連結終端機工作階段：Create another test pod and attach a terminal session:

kubectl run --rm -it --image=alpine network-policy --namespace development --generator=run-pod/v1

在 shell 提示字元中, wget使用來查看您是否可以存取預設的 NGINX 網頁。At the shell prompt, use wget to see if you can access the default NGINX webpage. 網路原則會封鎖輸入流量, 因此無法載入頁面, 如下列範例所示:The network policy blocks the inbound traffic, so the page can't be loaded, as shown in the following example:

$ wget -qO- --timeout=2 http://backend

wget: download timed out

結束連結的終端機工作階段。Exit out of the attached terminal session. 測試 pod 會自動刪除。The test pod is automatically deleted.

exit

只允許來自已定義命名空間的流量Allow traffic only from within a defined namespace

在先前的範例中, 您建立了拒絕所有流量的網路原則, 然後更新原則以允許來自具有特定標籤的 pod 流量。In the previous examples, you created a network policy that denied all traffic, and then updated the policy to allow traffic from pods with a specific label. 另一個常見的需求是將流量限制在指定的命名空間內。Another common need is to limit traffic to only within a given namespace. 如果先前的範例是針對開發命名空間中的流量, 請建立網路原則來防止來自另一個命名空間 (例如生產環境) 的流量到達 pod。If the previous examples were for traffic in a development namespace, create a network policy that prevents traffic from another namespace, such as production, from reaching the pods.

首先，建立新的命名空間，以模擬生產命名空間：First, create a new namespace to simulate a production namespace:

kubectl create namespace production
kubectl label namespace/production purpose=production

在標籤為 app=webapp,role=frontend 的 production 命名空間中排程測試 Pod。Schedule a test pod in the production namespace that is labeled as app=webapp,role=frontend. 連結終端機工作階段：Attach a terminal session:

kubectl run --rm -it frontend --image=alpine --labels app=webapp,role=frontend --namespace production --generator=run-pod/v1

在 shell 提示字元中, wget使用來確認您可以存取預設的 NGINX 網頁:At the shell prompt, use wget to confirm that you can access the default NGINX webpage:

wget -qO- http://backend.development

因為 pod 的標籤符合網路原則中目前允許的內容, 所以允許流量。Because the labels for the pod match what is currently permitted in the network policy, the traffic is allowed. 網路原則不會查看命名空間，只會查看 Pod 標籤。The network policy doesn't look at the namespaces, only the pod labels. 下列範例輸出會顯示傳回的預設 NGINX 網頁:The following example output shows the default NGINX webpage returned:

<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
[...]

結束連結的終端機工作階段。Exit out of the attached terminal session. 測試 pod 會自動刪除。The test pod is automatically deleted.

exit

更新網路原則Update the network policy

讓我們將 [輸入規則namespaceSelector ] 區段更新為只允許來自開發命名空間內的流量。Let's update the ingress rule namespaceSelector section to only allow traffic from within the development namespace. 編輯 backend-policy.yaml 資訊清單檔，如下列範例所示：Edit the backend-policy.yaml manifest file as shown in the following example:

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: backend-policy
  namespace: development
spec:
  podSelector:
    matchLabels:
      app: webapp
      role: backend
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          purpose: development
      podSelector:
        matchLabels:
          app: webapp
          role: frontend

在更複雜的範例中, 您可以定義多個輸入規則, 例如namespaceSelector和podSelector。In more complex examples, you could define multiple ingress rules, like a namespaceSelector and then a podSelector.

使用kubectl apply命令來套用已更新的網路原則, 並指定 YAML 資訊清單的名稱:Apply the updated network policy by using the kubectl apply command and specify the name of your YAML manifest:

kubectl apply -f backend-policy.yaml

測試已更新的網路原則Test the updated network policy

排程生產環境命名空間中的另一個 pod, 並附加終端機會話:Schedule another pod in the production namespace and attach a terminal session:

kubectl run --rm -it frontend --image=alpine --labels app=webapp,role=frontend --namespace production --generator=run-pod/v1

在 shell 提示字元中, wget使用來查看網路原則現在拒絕流量:At the shell prompt, use wget to see that the network policy now denies traffic:

$ wget -qO- --timeout=2 http://backend.development

wget: download timed out

結束測試 Pod：Exit out of the test pod:

exit

從生產命名空間拒絕流量後, 請在開發命名空間中排程測試 pod, 並附加終端機會話:With traffic denied from the production namespace, schedule a test pod back in the development namespace and attach a terminal session:

kubectl run --rm -it frontend --image=alpine --labels app=webapp,role=frontend --namespace development --generator=run-pod/v1

在 shell 提示字元中, wget使用來查看網路原則允許流量:At the shell prompt, use wget to see that the network policy allows the traffic:

wget -qO- http://backend

允許流量, 因為 pod 是在命名空間中排程, 符合網路原則中允許的專案。Traffic is allowed because the pod is scheduled in the namespace that matches what's permitted in the network policy. 下列範例輸出會顯示傳回的預設 NGINX 網頁:The following sample output shows the default NGINX webpage returned:

<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
[...]

結束連結的終端機工作階段。Exit out of the attached terminal session. 測試 pod 會自動刪除。The test pod is automatically deleted.

exit

清除資源Clean up resources

在本文中, 我們建立了兩個命名空間並套用網路原則。In this article, we created two namespaces and applied a network policy. 若要清除這些資源, 請使用kubectl delete命令並指定資源名稱:To clean up these resources, use the kubectl delete command and specify the resource names:

kubectl delete namespace production
kubectl delete namespace development

後續步驟Next steps

如需網路資源的詳細資訊, 請參閱Azure Kubernetes Service 中應用程式的網路概念 (AKS)。For more about network resources, see Network concepts for applications in Azure Kubernetes Service (AKS).

若要深入瞭解原則, 請參閱Kubernetes 網路原則。To learn more about policies, see Kubernetes network policies.