在 EKS 自動模式中使用網路政策 - Amazon EKS
概觀開始使用其運作方式？考量事項

協助改進此頁面

本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

若要為本使用者指南貢獻內容，請點選每個頁面右側面板中的在 GitHub 上編輯此頁面連結。

本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

在 EKS 自動模式中使用網路政策

概觀

隨著客戶使用 EKS 擴展其應用程式環境，網路流量隔離變得越來越基本，以防止未經授權存取叢集內外的資源。在叢集中並排執行多個不相關工作負載的多租戶環境中，這一點尤其重要。Kubernetes 網路政策可讓您增強 Kubernetes 工作負載的網路安全狀態，以及其與叢集外部端點的整合。EKS Auto Mode 支援不同類型的網路政策。

第 3 層和第 4 層隔離

標準 Kubernetes 網路政策會在 OSI 網路模型的第 3 層和第 4 層運作，可讓您控制 Amazon EKS 叢集內 IP 地址或連接埠層級的流量流程。

使用案例

  • 分割工作負載之間的網路流量，以確保只有相關的應用程式可以互相通訊。

  • 使用 政策在命名空間層級隔離租用戶，以強制執行網路分離。

以 DNS 為基礎的強制執行

客戶通常會在 EKS 中部署屬於更廣泛分散式環境的工作負載，其中一些工作負載必須與叢集外部的系統和服務 （北向流量） 通訊。這些系統和服務可以 AWS 位於 AWS 雲端或外部。以網域名稱系統 (DNS) 為基礎的政策可讓您採用更穩定且可預測的方法，來防止未經授權的 Pod 存取叢集外部資源或端點，以強化您的安全狀態。此機制不需要手動追蹤和允許列出特定 IP 地址。透過以 DNS 為基礎的方法保護資源，您還可以更靈活地更新外部基礎設施，而無需在上游伺服器和主機變更時放寬安全狀態或修改網路政策。您可以使用完整網域名稱 (FQDN) 或 DNS 網域名稱的相符模式，篩選外部端點的輸出流量。這可讓您靈活地擴展對與特定叢集外部端點相關聯的多個子網域的存取。

使用案例

  • 標準化以 DNS 為基礎的方法來篩選從 Kubernetes 環境到叢集外部端點的存取。

  • 安全存取多租戶環境中 AWS 的服務。

  • 管理混合雲端環境中從 Pod 到內部部署工作負載的網路存取。

管理員 （或叢集範圍） 規則

在某些情況下，如同多租戶案例，客戶可能需要強制執行適用於整個叢集的網路安全標準。您可以使用單一政策集中管理叢集中不同工作負載的網路存取控制，而不重複定義和維護每個命名空間的不同政策，無論其命名空間為何。這些類型的政策可讓您擴展在第 3 層、第 4 層和使用 DNS 規則時套用之網路篩選規則的強制執行範圍。

使用案例

  • 集中管理 EKS 叢集中所有 （或一部分） 工作負載的網路存取控制。

  • 定義整個叢集的預設網路安全狀態。

  • 以更具營運效率的方式，將組織安全標準擴展到叢集的範圍。

開始使用

先決條件

  • 已啟用 EKS 自動模式的 Amazon EKS 叢集

  • kubectl 已設定為連接到您的叢集

步驟 1：啟用網路政策控制器

要在 EKS 自動模式中使用網路政策，您首先需要透過將 ConfigMap 套用到您的叢集，以啟用網路政策控制器。

  1. 建立名為 enable-network-policy.yaml 且具有下列內容的檔案：

    apiVersion: v1
kind: ConfigMap
metadata:
  name: amazon-vpc-cni
  namespace: kube-system
data:
  enable-network-policy-controller: "true"

  2. 將 ConfigMap 套用至您的叢集：

    kubectl apply -f enable-network-policy.yaml

步驟 2：建立和測試網路政策

您的 EKS 自動模式叢集現已設定為支援 Kubernetes 網路政策。您可利用 Amazon EKS 的網路政策的星示範 來測試此功能。

步驟 3：調整節點類別中的網路政策代理程式組態 （選用）

您可以選擇性地建立新的節點類別，以變更節點上網路政策代理程式的預設行為，或啟用網路政策事件的記錄。若要這麼做，請依照下列步驟進行：

  1. 建立或編輯節點類別 YAML 檔案 (例如 nodeclass-network-policy.yaml)，內容如下：

    apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
  name: network-policy-config
spec:
  # Optional: Changes default network policy behavior
  networkPolicy: DefaultAllow
  # Optional: Enables logging for network policy events
  networkPolicyEventLogs: Enabled
  # Include other Node Class configurations as needed

  2. 將節點類別組態套用至您的叢集：

    kubectl apply -f nodeclass-network-policy.yaml

  3. 確認節點類別是否已建立：

    kubectl get nodeclass network-policy-config

  4. 更新您的節點集區，使其使用此節點類別。如需詳細資訊，請參閱為 EKS 自動模式建立節點集區。

其運作方式？

DNS 型網路政策

在 EKS Auto 中套用 DNS 型政策時的工作流程圖解
在 EKS Auto 中套用 DNS 型政策時的工作流程語彙

  1. 平台團隊會將 DNS 型政策套用至 EKS 叢集。

  2. 網路政策控制器負責監控叢集內政策的建立，然後協調政策端點。在此使用案例中，網路政策控制器會指示節點代理程式，根據所建立政策中允許列出的網域來篩選 DNS 請求。允許使用 FQDN 或符合 Kubernetes 資源組態中定義模式的網域名稱來列出網域名稱。

  3. 工作負載 嘗試解析叢集外部端點的 IP。DNS 請求會先經過代理，根據透過網路政策套用的允許清單來篩選這類請求。

  4. 一旦 DNS 請求通過 DNS 篩選條件允許清單，它會代理至 CoreDNS，

  5. CoreDNS 會接著將請求傳送至外部 DNS 解析程式 (Amazon Route 53 Resolver)，以取得網域名稱後方的 IP 地址清單。

  6. 在對 DNS 請求的回應中傳回具有 TTL 的已解析 IPs。然後，這些 IPs會寫入 eBPF 映射中，用於執行 IP 層的下一個步驟。

  7. 接著，連接至 Pod 實物界面的 eBPF 探查會根據適當的規則，篩選從工作負載 A 到叢集外部端點的輸出流量。這可確保 Pod 只能將叢集外部流量傳送至允許所列網域IPs。這些 IPs 的有效性是以從外部 DNS 解析程式 (Amazon Route 53 Resolver) 擷取的 TTL 為基礎。

使用應用程式網路政策

ApplicationNetworkPolicy 結合了標準 Kubernetes 網路政策的功能，以及使用單一自訂資源定義 (CRD) 在命名空間層級進行以 DNS 為基礎的篩選。因此， ApplicationNetworkPolicy可用於：

  1. 使用 IP 區塊和連接埠號碼，定義網路堆疊第 3 層和第 4 層的限制。

  2. 定義在網路堆疊第 7 層操作的規則，並讓您根據 FQDNs篩選流量。

重要注意事項：使用 定義的 DNS 型規則ApplicationNetworkPolicy僅適用於在 EKS Auto Mode 啟動的 EC2 執行個體中執行的工作負載。

範例

EKS Auto Mode 叢集中有工作負載，需要與具有 DNS 名稱的負載平衡器後方的應用程式內部部署通訊。您可以使用下列網路政策來達成此目的：

apiVersion: networking.k8s.aws/v1alpha1
kind: ApplicationNetworkPolicy
metadata:
  name: my-onprem-app-egress
  namespace: galaxy
spec:
  podSelector:
    matchLabels:
      role: backend
  policyTypes:
  - Egress
  egress:
  - to:
    - domainNames:
      - "myapp.mydomain.com"
    ports:
    - protocol: TCP
      port: 8080

在 Kubernetes 網路層級，這將允許從標記為 的「galaxy」命名空間中的任何 Pod 輸出role: backend，以連接到 TCP 連接埠 8080 上的網域名稱 myapp.mydomain.com。此外，您需要為從 VPC 到公司資料中心的輸出流量設定網路連線。

EKS Auto 中的工作負載llustration 與內部部署上的應用程式通訊

管理員 （或叢集） 網路政策

EKS 網路政策評估順序的虛構

使用叢集網路政策

使用 時ClusterNetworkPolicy，會先評估管理員層政策，且無法覆寫。評估管理員層政策後，會使用標準命名空間範圍政策來執行套用的網路分割規則。這可以透過使用 ApplicationNetworkPolicy或 來完成NetworkPolicy。最後，將強制執行定義叢集工作負載預設網路限制的基準層規則。如有需要，命名空間範圍政策可以覆寫這些基準層規則。

範例

您的叢集中有您要隔離其他租用戶工作負載的應用程式。您可以明確封鎖來自其他命名空間的叢集流量，以防止網路存取敏感工作負載命名空間。

apiVersion: networking.k8s.aws/v1alpha1
kind: ClusterNetworkPolicy
metadata:
  name: protect-sensitive-workload
spec:
  tier: Admin
  priority: 10
  subject:
    namespaces:
      matchLabels:
        kubernetes.io/metadata.name: earth
  ingress:
    - action: Deny
      from:
      - namespaces:
          matchLabels: {} # Match all namespaces.
      name: select-all-deny-all

考量事項

了解政策評估順序

EKS 中支援的網路政策功能會以特定順序評估，以確保可預測且安全的流量管理。因此，請務必了解評估流程，為您的環境設計有效的網路安全狀態。

  1. 管理員層政策 （先評估）：所有管理員層 ClusterNetworkPolicies 都會在任何其他政策之前進行評估。在管理員層中，政策會依優先順序處理 （優先順序最低的數字優先）。動作類型會決定接下來會發生的情況。

    • 拒絕動作 （最高優先順序）：當具有拒絕動作的管理員政策符合流量時，無論任何其他政策為何，都會立即封鎖該流量。不會處理其他 ClusterNetworkPolicy 或 NetworkPolicy 規則。這可確保命名空間層級政策不會覆寫整個組織的安全控制。

    • 允許動作：評估拒絕規則之後，具有允許動作的管理員政策會依優先順序處理 （優先順序最低的數字優先）。當允許動作相符時，系統會接受流量，而不會進一步評估政策。這些政策可以根據標籤選擇器授予跨多個命名空間的存取權，從而集中控制哪些工作負載可以存取特定資源。

    • 傳遞動作：在管理層政策中傳遞動作，將決策委派給較低的層。當流量符合通過規則時，評估會略過該流量的所有剩餘管理員層規則，並直接進入 NetworkPolicy 層。這可讓管理員將特定流量模式的控制明確委派給應用程式團隊。例如，您可以使用 Pass 規則將命名空間內流量管理委派給命名空間管理員，同時對外部存取維持嚴格的控制。

  2. 網路政策方案：如果沒有管理員方案政策與拒絕或允許相符，或者傳遞動作相符，則會評估命名空間範圍的 ApplicationNetworkPolicy 和傳統 NetworkPolicy 資源。這些政策可在個別命名空間內提供精細的控制，並由應用程式團隊管理。命名空間範圍政策只能比管理員政策更嚴格。他們無法覆寫管理員政策的拒絕決策，但可以進一步限制管理員政策允許或傳遞的流量。

  3. 基準層管理員政策：如果沒有管理員或命名空間範圍的政策符合流量，則會評估基準層 ClusterNetworkPolicies。這些提供可由命名空間範圍政策覆寫的預設安全狀態，允許管理員設定整個組織的預設值，同時為團隊提供視需要自訂的彈性。基準政策會依優先順序 （優先順序最低的數字優先） 進行評估。

  4. 預設拒絕 （如果沒有政策相符）：此deny-by-default行為可確保只允許明確允許的連線，並維持強大的安全狀態。

套用最低權限原則

  • 從限制性政策開始，並視需要逐步新增許可 - 首先在叢集層級實作deny-by-default政策，然後在驗證合法連線需求時逐步新增允許規則。這種方法會強制團隊明確地證明每個外部連線的合理性，建立更安全且可稽核的環境。

  • 定期稽核並移除未使用的政策規則 - 網路政策會隨著應用程式演進而隨著時間累積，留下不必要地擴展攻擊面的過時規則。實作定期審查程序，以識別和移除不再需要的政策規則，確保您的安全狀態保持緊密且可維護。

  • 盡可能使用特定的網域名稱，而不是廣泛的模式 - 雖然萬用字元模式*.amazonaws.com可提供便利性，但它們也會授予對各種服務的存取權。可行時，請指定 之類的確切網域名稱s3.us-west-2.amazonaws.com，以限制僅存取應用程式所需的特定服務，在工作負載遭到入侵時降低橫向移動的風險。

在 EKS 中使用 DNS 型政策

  • 使用 定義的 DNS 型規則ApplicationNetworkPolicy僅適用於在 EKS Auto Mode 啟動 EC2 執行個體中執行的工作負載。如果您執行混合模式叢集 （由 EKS Auto 和非 EKS Auto 工作者節點組成），您的 DNS 型規則僅在 EKS Auto 模式工作者節點 (EC2 受管執行個體） 中有效。

驗證您的 DNS 政策

  • 使用反映生產網路拓撲的預備叢集進行測試 - 您的預備環境應該複寫生產的網路架構、外部相依性和連線模式，以確保準確的政策測試。這包括相符的 VPC 組態、DNS 解析行為，以及對生產工作負載所需的相同外部服務的存取。

  • 實作關鍵網路路徑的自動化測試 - 建置自動化測試，以驗證 CI/CD 管道中必要外部服務的連線能力。這些測試應驗證在封鎖未經授權的連線時是否允許合法流量流程，提供持續驗證，讓您的網路政策隨著基礎設施的演進而維持正確的安全狀態。

  • 在政策變更後監控應用程式行為 - 在將新的或修改的網路政策部署至生產環境之後，請密切監控應用程式日誌、錯誤率和效能指標，以快速識別任何連線問題。建立明確的轉返程序，以便在政策變更造成非預期的應用程式行為或服務中斷時，快速還原政策變更。

與 Amazon Route 53 DNS 防火牆的互動

啟動流量時，EKS Admin 和 Network 政策會先在 Pod 層級進行評估。如果 EKS 網路政策允許輸出到特定網域，則 Pod 會執行到達 Route 53 Resolver 的 DNS 查詢。此時會評估 Route 53 DNS 防火牆規則。如果 DNS 防火牆封鎖網域查詢，DNS 解析會失敗，而且即使 EKS 網路政策允許，也無法建立連線。這會建立互補的安全層：EKS DNS 型網路政策為應用程式特定的存取要求和多租用戶安全界限提供 Pod 層級的輸出控制，而 DNS 防火牆針對已知惡意網域提供 VPC 整體保護，並強制執行整個組織的封鎖清單。