在 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. 網路原則應該只用於以 Linux 為基礎的節點和 AKS 中的 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 （進階） 選項。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 外掛程式 and define your own virtual network and subnets. For more detailed information on how to plan out the required subnet ranges, see configure advanced networking。To use network policy with an AKS cluster, you must use the Azure CNI plug-in and define your own virtual network and subnets. 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.
• 建立 Azure Active Directory (Azure AD) 使用的服務主體與 AKS 叢集。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:

SP_PASSWORD=mySecurePassword
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_ID=$(az ad sp create-for-rbac --password $SP_PASSWORD --skip-assignment --query [appId] -o tsv)

# 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若要使用連線到 Kubernetes 叢集az aks get-credentials 來取得認證命令。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

在殼層提示字元中，使用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

既然您已確認您可以使用基本的 NGINX 網頁上的範例後端 pod，請建立網路原則以拒絕所有流量。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若要將原則附加至有的 pod app:webapp，角色： 後端標籤，例如範例 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 套用命令並指定您的 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

在殼層提示字元中，使用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. 編輯先前後端 policy.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 套用命令並指定您的 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

排程會標示為 pod應用程式 = webapp，角色 = frontend並附加終端機工作階段：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

在殼層提示字元中，使用wget如果您可以存取預設 NGINX 網頁：At the shell prompt, use wget to see if you can access the default NGINX webpage:

wget -qO- http://backend

因為輸入規則允許流量： 其標籤的 pod應用程式： webapp，角色： 前端，允許流量從前端的 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

在殼層提示字元中，使用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

在殼層提示字元中，使用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 套用命令並指定您的 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

在殼層提示字元中，使用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

在殼層提示字元中，使用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 刪除命令並指定資源名稱：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.