Azure Kubernetes Service (AKS) 中的網路連線和安全性最佳做法

發行項
04/07/2024

當您在 Azure Kubernetes Service (AKS) 中建立及管理叢集時，您會為節點和應用程式提供網路連線。這些網路資源包括 IP 位址範圍、負載平衡器和輸入控制器。

此最佳做法文章著重於叢集操作員的網路連線能力和安全性。在本文中，您將學會如何：

將 AKS 內的 kubenet 和 Azure 容器網路介面 (CNI) 網路模式拿來做比較。
規劃所需的 IP 位址和連線能力
將負載平衡器、輸入控制器或 Web 應用程式防火牆 (WAF) 用來散發流量。
安全地連線到叢集節點

選擇適當的網路模型

最佳做法指導方針

若要整合現有虛擬網路或內部部署網路，請使用 AKS 內的 Azure CNI 網路功能。此網路模型，也能讓企業環境中的資源和控制項，達到更有效的區分。

虛擬網路會提供存取您應用程式的基本連線能力給 AKS 節點和客戶。將 AKS 叢集部署到虛擬網路有兩種不同的方式：

Azure CNI 網路：部署至虛擬網路，且使用 Azure CNI Kubernetes 外掛程式。 Pod 會收到可路由到其他網路服務或內部部署資源的個別 IP。
Kubenet 網路功能：Azure 會在叢集部署好之後管理虛擬網路資源，並使用 kubenet Kubernetes 外掛程式。

針對生產環境部署，Azure CNI 和 kubenet 都是有效選項。

CNI 網路

容器網路介面 (CNI) 是一個廠商中立的通訊協定，能讓執行階段的容器對於網路提供者提出要求。 Azure CNI 會將 IP 位址指派給 Pod 和節點，並在您連線至現有 Azure 虛擬網路時，提供 IP 位址管理 (IPAM) 功能。每個節點和 Pod 資源都會在 Azure 虛擬網路中收到一個 IP 位址。不需要額外的路由即可與其他資源或服務通訊。

顯示兩個節點的網橋連線到單一 Azure VNet 的圖表

值得注意的是，適用於生產環境的 Azure CNI 網路，可分隔資源的控制和管理。從安全性觀點來看，您通常會想讓不同小組來管理及保護這些資源。執行 Azure CNI 網路功能，可讓您透過指派給每個 Pod 的 IP 位址，直接連線到現有的 Azure 資源、內部部署資源或其他服務。

當您使用 Azure CNI 網路功能時，虛擬網路資源會在 AKS 叢集的不同資源群組中。您可以將存取和管理這些資源的權限委派給 AKS 服務主體。 AKS 叢集使用的叢集身分識別在虛擬網路內的子網路上至少必須包含 Network Contributor 權限。

如果您想要定義自訂角色，而不使用內建的網路參與者角色，則需要下列權限：

Microsoft.Network/virtualNetworks/subnets/join/action
Microsoft.Network/virtualNetworks/subnets/read

根據預設，AKS 會針對其叢集識別來使用受控識別。不過，您可以改用服務主體。

如需有關 AKS 服務主體委派的詳細資訊，請參閱委派其他 Azure 資源的存取權。
如需受控識別的詳細資訊，請參閱使用受控識別。

當每個節點和 Pod 收到自己的 IP 位址時，請規劃 AKS 子網路的位址範圍。請記住下列準則：

子網路必須夠大，才能為您部署的每個節點、Pod 和網路資源提供 IP 位址。
- Kubenet 和 Azure CNI 網路都會預設每個正在執行節點的 Pod 數目限制。
要避免使用與現有網路資源重疊的 IP 位址範圍。
- 必須允許連線到 Azure 中的內部部署或同儕節點網路。
若要處理擴大事件或將叢集升級，您也需要其他能在已指派子網路中所使用的 IP 位址。
- 如果您使用 Windows Server 容器，這個額外的位址空間非常重要，因為需要將這些節點集區升級，才能套用最新的安全性修補檔。如需關於升級 Windows Server 節點集區的詳細資訊，請參閱在 AKS 內升級節點集區。

若要計算所需的 IP 位址，請參閱在 AKS 中設定 Azure CNI 網路功能。

使用 Azure CNI 網路建立叢集時，您可以指定叢集的其他位址範圍，例如 Docker 橋接器位址、DNS 服務 IP 和服務位址範圍。一般而言，請確定這些位址範圍不會彼此重疊，而且不會與叢集相關聯的任何網路有重疊，包括任何虛擬網路、子網、內部部署和對等式網路。

如果需要這些位址範圍限制和調整大小的特定詳細資料，請參閱在 AKS 內設定 Azure CNI 網路功能。

Kubenet 網路

雖然 kubenet 不需要在部署叢集之前預先設定虛擬網路，但也是有一些缺點，比如：

由於節點和 Pod 位於不同的 IP 子網路上，因此使用者定義路由 (UDR) 和 IP 轉送路由，都會傳送 Pod 與節點之間的流量。此額外的路由會降低網路效能。
連線至現有內部部署網路或與其他 Azure 虛擬網路對等互連可能會很複雜。

由於您不會與 AKS 叢集分開建立虛擬網路和子網路，因此 kubenet 非常適用於下列案例：

小型開發或測試工作負載。
具有低流量的簡易網站。
將工作負載轉移至容器。

針對生產環境部署，kubenet 和 Azure CNI 都是有效的選項。需要區隔控制和管理的環境，Azure CNI 可能是慣用的選項。此外，kubenet 僅適用於 IP 位址範圍保護是優先的 Linux 環境。

您也可以使用 kubenet 設定自己的 IP 位址範圍和虛擬網路。如同 Azure CNI 網路，這些位址範圍彼此不應該重疊，而且不應該與叢集相關聯的網路有任何重疊 (虛擬網路、子網路、內部部署和對等式網路)。

如需這些位址範圍限制和調整大小的特定詳細資料，請參閱在 AKS 內使用 kubenet 網路與您自己上的 IP 位址範圍。

分配輸入流量

最佳做法指導方針

若要將 HTTP 或 HTTPS 流量分散至應用程式，請使用輸入資源和控制器。輸入控制器會透過 Azure 負載平衡器來提供額外的功能，並且為可受控的原生 Kubernetes 資源。

Azure 負載平衡器能將客戶流量散發至 AKS 叢集內的應用程式，但會受限於應用程式對該流量的瞭解程度。負載平衡器資源會在第 4 層上運作，並根據通訊協定或連接埠分散流量。

大部分使用 HTTP 或 HTTPS 的 Web 應用程式，應當使用於第 7 層所運作的 Kuberenetes 輸入資源和控制器。輸入可以根據應用程式的 URL 將流量分散到應用程式，並處理 TLS/SSL 終止。輸入也會減少您公開並對應的 IP 位址數目。

若使用負載平衡器，每個應用程式通常需要指派並對應至 AKS 叢集中服務的公用 IP 位址。若使用輸入資源，單一 IP 位址可以將流量分散到多個應用程式。

顯示 AKS 叢集中輸入流量流量的圖表

輸入有兩個元件：

輸入資源
輸入「控制器」

輸入資源

輸入資源為 YAML 資訊清單的kind: Ingress。它定義了主機、憑證以及將路由流量傳送至 AKS 叢集內所執行的服務規則。

下列範例 YAML 指令清單會將 myapp.com 流量散發至下列兩個服務之一：blogservice 或 storeservice，並根據客戶存取的 URL 將客戶導向至其中一項服務。

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
 name: myapp-ingress
spec:
 ingressClassName: PublicIngress
 tls:
 - hosts:
   - myapp.com
   secretName: myapp-secret
 rules:
   - host: myapp.com
     http:
      paths:
      - path: /blog
        backend:
         service:
           name: blogservice
           port: 80
      - path: /store
        backend:
         service:
           name: storeservice
           port: 80

輸入控制器

輸入控制器為在 AKS 節點上執行的精靈，可監看傳入的要求。接著，流量會根據輸入資源中所定義的規則來分配。雖然最常見的輸入控制器為以 NGINX 為基礎，但 AKS 不會限制您至特定的控制器。您可以使用 Contour、HAProxy、Traefik等等。

輸入控制器務必在 Linux 節點上排程。指出資源，應當在以 Linux 為基礎的節點上執行的 YAML 資訊清單或 Helm 圖表部署中的節點選取器來使用。如需詳細資訊，請參閱使用在 AKS 內已排程的節點選取器來控制 Pod。

使用應用程式路由附加元件輸入

應用程式路由附加元件是在 AKS 中設定輸入控制器的建議方式。應用程式路由附加元件是適用於 Azure Kubernetes Service (AKS) 的完全受控輸入控制器，可提供下列功能：

根據 Kubernetes NGINX 輸入控制器，輕鬆設定受控 NGINX 輸入控制器。
與 Azure DNS 整合，以進行公用和私人區域管理。
使用儲存於 Azure Key Vault 中的憑證進行 SSL 終止。

如需應用程式路由附加元件的詳細資訊，請參閱使用應用程式路由附加元件管理的 NGINX 輸入。

使用 Web 應用程式防火牆 (WAF) 來保護流量

最佳做法指導方針

如果要掃描傳入的流量來查看是否有潛在攻擊，請使用 Web 應用程式防火牆 (WAF)，例如，適用於 Azure 的 Barracuda WAF 或 Azure 應用程式閘道。這些更進階的網路資源也能進行路由流量，並非僅限於 HTTP 和 HTTPS 連線或是基本的 TLS 終止。

將流量散發至服務和應用程式的輸入控制器，通常為 AKS 叢集中的 Kubernetes 資源。控制器會以精靈形式在 AKS 節點上執行，並取用一些節點的資源，例如 CPU、記憶體和網路頻寬。在更大的環境中，您可能會想要考慮下列因素：

卸載一些流量路由或 TLS 終止至 AKS 叢集外部的網路資源。
掃描傳入的流量以查看是否有潛在攻擊。

Azure 應用程式閘道之類的 Web 應用程式防火牆（WAF）可以保護及散發 AKS 叢集的流量

針對那額外的安全性圖層，Web 應用程式防火牆 (WAF) 會篩選傳入流量。 Open Web Application Security Project (OWASP) 會提供一組規則以監看是否有跨網站指令碼或 Cookie 破壞等攻擊。 Azure 應用程式閘道(目前在 AKS 為預覽版) 是可與 AKS 叢集整合的 WAF，可在流量到達 AKS 叢集和應用程式前，鎖定這些安全性功能。

由於其他第三方解決方案也會執行這些功能，因此，您可以在指定產品中繼續使用現有的投資或專長。

負載平衡器或輸入資源會繼續在 AKS 叢集內執行，以進一步將流量分配精簡。您可以使用資源定義，將應用程式閘道當作輸入控制器來集中管理。若要開始使用，請建立應用程式閘道輸入控制器。

使用網路原則控制流量流程

最佳做法指導方針

使用網路原則來允許或拒絕 Pod 的流量。根據預設，叢集內 Pod 之間允許所有流量。為了提升安全性，請定義限制 Pod 通訊的規則。

網路原則是 AKS 中提供的 Kubernetes 功能，可以控制 OPod 之間的流量。可以根據指派的標籤、命名空間或流量連接埠等設定來允許或拒絕至 Pod 的流量。網路原則是控制 Pod 流量的雲端原生方式。由於 Pod 是在 AKS 叢集中動態建立的，因此可以自動套用所需的網路原則。

如果要使用網路原則，必須在建立新的 AKS 叢集時啟用該功能。您無法在現有的 AKS 叢集上啟用網路原則。事先規劃，藉以在必要的叢集上啟用網路原則。

注意

網路原則只應用於 AKS 中的 Linux 型節點和 Pod。

使用 YAML 資訊清單將網路原則建立成 Kubernetes 資源。原則會套用至已定義的 Pod，其中包含以輸入或輸出規則來定義流量流程。

下列範例將網路原則套用至已套用 app: backend 標籤的 Pod。輸入規則僅允許來自具有 app: frontend 標籤的 Pod 流量。

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: backend-policy
spec:
  podSelector:
    matchLabels:
      app: backend
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: frontend

若要開始使用原則，請參閱使用 Azure Kubernetes Service (AKS) 中的網路原則保護 Pod 之間的流量。

透過堡壘主機安全地連線至節點

最佳做法指導方針

請勿對您的 AKS 節點公開遠端連線能力。在管理虛擬網路中建立防禦主機或跳躍箱 (jump box)。您可以使用防禦主機安全地將流量路由到 AKS 叢集，以完成遠端管理工作。

在 AKS 內，大部分的作業都可使用 Azure 管理工具或透過 Kubernetes API 伺服器來完成。 AKS 節點不會連線至公用網路，而只會於私人網路上提供。如果要連線至節點並提供維護與支援，請透過堡壘主機或跳板機，執行路由連線。確認此主機位於 AKS 叢集虛擬網路的個別且安全對等式管理的虛擬網路中。

使用防禦主機或跳躍方塊連線至 AKS 節點

同時也應該保護堡壘主機的管理網路。使用 Azure ExpressRoute 或 VPN 閘道來連線到內部部署網路，並使用網路安全性群組來控制存取。

下一步

本文著重於網路連線和安全性。若要深入瞭解 Kubernetes 中的網路基本概念，請參閱 Azure Kubernetes Service (AKS) 中應用程式的網路概念

共用方式為