預設 Calico 及 Kubernetes 網路原則

建立具有公用 VLAN 的叢集時，會針對每個工作者節點及其公用網路介面，自動建立具有 HostEndpoint 標籤的 ibm.role: worker_public 資源。 此 HostEndpoint 會導致所有往返公共網路介面的流量均被拋棄，除非該流量已由選取 ibm.role: worker_public 標籤的 Calico 政策明確允許。

也會針對每一個工作者節點及其專用網路介面自動建立具有 ibm.role: worker_private 標籤的 HostEndpoint 資源。 會建立預設 allow-all-private-default 原則，以便容許所有資料流量進出專用網路介面。 此 HostEndpoint 可透過建立選取 ibm.role: worker_private 且訂單號碼低於 allow-all-private-default 的 Calico 原則，讓叢集使用者輕鬆地進一步限制專用網路資料流量。

這些預設的 Calico 主機政策允許所有對外發出的公共網路流量，並允許針對特定叢集元件（例如 Kubernetes、NodePort,、LoadBalancer, 以及 Ingress 服務）的公共入站流量。 依預設，allow-all-private-default 原則容許所有專用資料流量。 任何未在預設政策中指定的、從網際網路傳入您工作節點的其他網路流量，都會被封鎖。 預設原則不會影響 Pod 至 Pod 的資料流量。

請勿從叢集中移除預設原則，因為它們會在下一次叢集主節點重新整理或主節點更新時重建。 若要進一步限制流量，請套用優先級較低的 Calico 政策來封鎖該流量。 請確定您完全瞭解正在封鎖的內容，且叢集元件不需要您要封鎖的資料流量。

檢閱下列自動套用至叢集的預設 Calico 主機原則。

系統亦會建立預設的「Kubernetes」政策，用以限制對「Kubernetes」儀表板的存取權限。 Kubernetes 原則不會套用至主機端點，而是改為套用至 Pod 層次，以及所有標準及 VPC 叢集。

安裝並配置 Calico CLI

若要檢視、管理及新增 Calico 原則，請安裝並配置 Calico CLI。

1. 設定叢集的環境定義以執行 Calico 指令。

   • Kubernetes 1.19 版以及更新版本:

     1. 請下載適用於您叢集的 kubeconfig 設定檔。

        ibmcloud ks cluster config --cluster CLUSTER_NAME_OR_ID
        

     2. 將 DATASTORE_TYPE 環境變數設為 kubernetes。

        export DATASTORE_TYPE=kubernetes
        

2. 如果組織網路原則使用 Proxy 或防火牆，來阻止從本端系統存取公用端點，請容許 Calico 指令的 TCP 存取。

3. 遵循步驟來安裝 calicoctl 指令行工具。

   • Linux 以及 OS X

     1. 下載符合您作業系統的 Calico CLI 版本。 對於 OS X，您可能需要導覽至 系統喜好設定 > 安全與隱私權 > 一般，以手動容許開啟及執行下載的檔案。

     2. 將檔案移至 /usr/local/bin 目錄中。

        mv <filepath>/<filename> /usr/local/bin/calicoctl
        

     3. 讓檔案成為可執行檔。

        chmod +x /usr/local/bin/calicoctl
        

     4. 確保 /etc/calico 目錄中沒有舊的 Calico 配置檔 calicoctl.cfg。 如果 /etc/calico/calicoctl.cfg 檔案存在，請刪除它。

   • Windows

     1. 下載 Calico CLI。 當您儲存檔案時，請將它重新命名為 calicoctl.exe，並將它儲存在與 IBM Cloud CLI 相同的目錄中。 當您稍後執行指令時，這項設定可為您省去一些檔案路徑變更。

     2. 將環境變數設為叢集的配置檔。

        export KUBECONFIG=./.bluemix/plugins/container-service/clusters/<cluster_name>-<hash>/kube-config.yaml
        

4. 驗證 Calico 配置正確運作。

   calicoctl get nodes
   

   輸出範例

   NAME
   10.176.48.106
   10.176.48.107
   10.184.58.23
   10.184.58.42
   ...
   

不支援變更「Calico」外掛程式、元件或預設的 Calico 設定。 例如，請勿部署新的 Calico 外掛程式版本，亦請勿修改 Calico 元件、預設 IPPool 資源或 Calico 節點 的守護程序集或部署。 相反地，您可以依照文件說明，變更 Calico 的MTU，或在必要時 停用 Calico CNI的端口映射外掛程式。

檢視網路原則

檢視預設值的詳細資料，以及任何已套用至叢集的新增網路原則。

開始之前，請 安裝並配置 Calico CLI，並設定叢集的環境定義以執行 Calico 指令。

1. 檢視 Calico 主機端點。

   calicoctl get hostendpoint -o yaml
   

2. 檢視為該叢集所建立的所有「Calico」網路原則。 此清單包含一些目前可能尚未套用至任何 Pod 或主機的政策。 若要強制執行 Calico 原則，Kubernetes Pod 或 Calico HostEndpoint 必須存在，且符合 Calico 網路原則中的選取器。

   網路政策的適用範圍限於特定命名空間：

   calicoctl get NetworkPolicy --all-namespaces -o wide
   

   全域網路政策不限於特定命名空間：

   calicoctl get GlobalNetworkPolicy -o wide
   

3. 檢視網路原則的詳細資料。

   calicoctl get NetworkPolicy -o yaml <policy_name> --namespace <policy_namespace>
   

4. 檢視叢集之所有廣域網路原則的詳細資料。

   calicoctl get GlobalNetworkPolicy -o yaml
   

新增網路原則

通常，預設原則不需要變更。 只有進階情境會有可能需要變更。 如果發現必須進行變更，則您可以建立自己的網路原則。

若要建立「Kubernetes」網路原則，請參閱 Kubernetes 上的網路原則文件。

若要建立 Calico 原則，請使用下列步驟。 開始之前，請 安裝並配置 Calico CLI，並設定叢集的環境定義以執行 Calico 指令。

1. 請透過建立符合 Calico v3 政策語法規範的配置腳本（.yaml ），來定義您的「Calico」網路政策或 全域網路政策。 這些配置檔包含選取器，其說明這些原則適用的 Pod、名稱空間或主機。

   對於在 1.29 或更新版本中建置的新叢集，globalnetworkpolicies.crd.projectcalico.org （gnp ）和 hostendpoints.crd.projectcalico.org （hep ）的簡稱將不被支援。 不過，若將叢集升級至 1.29 或更新版本，系統仍會支援這些簡稱。

2. 將原則套用至叢集。 如果您有 Windows 系統，請包含 --config=<filepath>/calicoctl.cfg 選項。

   calicoctl apply -f policy.yaml [--config=<filepath>/calicoctl.cfg]
   

請注意，Calico 及 Kubernetes 網路原則只會封鎖新連線，它們不會岔斷在套用原則之前存在的連線。 因此，在套用新的或已變更的原則之後，若要測試它是否正在運作且未封鎖超過它應該的項目，請執行下列動作:

1. 重新啟動任何可能受原則影響的 Pod。 最好是重新啟動所有 Pod，以防您沒有正確的選取元，而且它會影響您所認為的更多。

2. 執行 ibmcloud ks cluster master refresh -c CLUSTER-ID 以重新啟動叢集主節點 Pod。 這會岔斷從 kubelet 及其他元件到主要元件的現有連線，並強制它們重新連接。 這將顯示新的及變更的原則是否封鎖與主要元件的任何必要連線。

3. 嘗試連接至 Kubernetes 儀表板，以確保原則變更不會封鎖那些元件所需的連線。

控制 NLB 或 NodePort 服務的入埠資料流量

預設情況下， Kubernetes、NodePort 以及 LoadBalancer 服務會讓您的應用程式在所有公開及私有叢集介面上皆可存取。 不過，您可以根據資料流量來源或目的地，使用 Calico 原則來封鎖對您服務的送入資料流量。

由於為這些服務生成的 DNAT Iptables 規則，難以直接套用預設的 Kubernetes 和 Calico 政策來保護 Kubernetes、NodePort 以及 LoadBalancer 服務。 不過，DNAT 前原則可防止指定的資料流量到達您的應用程式，因為它們會在 Kubernetes 使用一般 DNAT 將資料流量轉遞至 Pod 之前產生並套用 Iptables 原則。

Calico DNAT 前網路原則的一些常見用途：

• 封鎖送入專用網路負載平衡器 (NLB) 服務的公用節點埠的資料流量：NLB 服務可讓您的應用程式透過 NLB IP 位址及埠提供使用，並讓您的應用程式可透過服務的節點埠提供使用。 叢集裡每個節點的每個 IP 位址（公開和專用）上都可以存取節點埠。
• 封鎖資料流量傳輸至叢集上正在執行邊緣工作者節點的公用節點埠：封鎖節點埠可確保邊緣工作者節點是處理送入資料流量的唯一工作者節點。
• 封鎖來自特定來源 IP 位址或 CIDR 區段的流量
• 僅允許來自特定來源 IP 位址或 CIDR 的流量，並封鎖所有其他流量

若要了解如何允許或封鎖來源 IP 位址，請參閱《 使用 Calico 網路政策封鎖流量》這篇教學指南。

用於限制公用或專用網路資料流量的 Calico 原則範例

我們提供了一組 Calico 公共網路政策 範例，用以進一步限制叢集工作節點上的公共／私有網路流量。 這些策略允許部署叢集所需的流量，並阻止某些其他流量。

這些原則並不是要封鎖一切，也不一定要自行符合任何法規遵循要求。 它們是作為起點，必須編輯以符合您的獨特使用案例。 如需相關資訊，請參閱 README。

每當啟用「IBM Cloud Kubernetes Service」及其他「IBM Cloud」的新位置時，這些位置的子網段便會新增至「Calico」政策中。 請務必 留意 GitHub 儲存庫，以掌握這些政策的任何更新。

請注意，我們不再建議使用「套用公共網路政策」和「套用私有網路政策」章節中列出的 allow-egress-pods-public、allow-public-services-pods、allow-egress-pods-private 或 allow-private-services-pods 範例政策。 這些策略控制群集中所有 Pod 的出口。 若要控制進出 Pod 的流量，應使用 Kubernetes NetworkPolicy，並針對特定命名空間和 Pod 進行設定，而非使用這些將每個 Pod 一視同仁的通用政策。

控制 Pod 之間的資料流量

Kubernetes 原則會保護 Pod 免於內部網路資料流量。 您可以建立簡單的 Kubernetes 網路政策，以在同一個命名空間內或跨命名空間之間，將應用程式微服務彼此隔離。

依預設，任何 Pod 都可以存取叢集裡的任何其他 Pod。 此外，任何 Pod 都可以存取 Pod 網路所公開的任何服務，例如度量服務、叢集 DNS、API 伺服器或您在叢集裡手動建立的任何服務。

記載被拒絕的資料流量

若要記載針對叢集裡的特定 Pod 而被拒絕的資料流量要求，您可以建立 Calico 日誌網路原則。

當您設定網路原則來限制應用程式 Pod 的資料流量時，這些原則所不允許的資料流量要求會遭到拒絕及捨棄。 在某些情況下，您可能想要取得被拒絕之資料流量要求的相關資訊。 例如，您可能會注意到不斷被您的其中一個網路原則拒絕的一些異常資料流量。 若要監視潛在的安全威脅，您可以設定記載，在每次原則拒絕所指定的應用程式 Pod 的嘗試動作時就進行記錄。

本節顯示如何記載 Kubernetes 網路原則所拒絕的資料流量。 若要記載 Calico 網路原則所拒絕的資料流量，請參閱 Calico 網路原則指導教學的第 5 課。

開始之前，請 安裝並配置 Calico CLI，並設定叢集的環境定義以執行 Calico 指令。

1. 建立或使用現有 Kubernetes 網路原則，以封鎖或限制送入的資料流量。

   1. 建立 Kubernetes 網路原則。 例如，要控制 Pod 之間的資料流量，可以使用名為 access-nginx 的下列範例 Kubernetes 原則，限制存取 NGINX 應用程式。 具有 "run=nginx" 標籤的 Pod 的送入資料流量，只能是來自具有 "run=access" 標籤的 Pod。 "run=nginx" 應用程式 Pod 的所有其他送入的資料流量會遭到封鎖。

       kind: NetworkPolicy
       apiVersion: networking.k8s.io/v1
       metadata:
        name: access-nginx
       spec:
        podSelector:
          matchLabels:
            run: nginx
        ingress:
          - from:
            - podSelector:
                matchLabels:
                  run: access
       ```
   2. 套用原則。
   
   ```sh {: pre}
       kubectl apply -f <policy_name>.yaml
       ```
   

2. 若要記載您在前一個步驟中建立的原則所拒絕的所有資料流量，請建立一個名為 log-denied-packets 的 Calico NetworkPolicy。 下列 Calico 原則使用與步驟 1 中所說明的範例 access-nginx Kubernetes 原則相同的 Pod 選取器，但語法略有不同，因為它是 Calico NetworkPolicy 而非 Kubernetes NetworkPolicy。 此外，因為所有 Kubernetes NetworkPolicy 都由 Calico 評估為訂單 1000，所以會新增訂單號碼 3000，以確保在 Kubernetes NetworkPolicy之後進行評估。 有了這兩項原則，結果如下:

   • 首先會根據 Kubernetes NetworkPolicy (訂單 1000) 來評估進入 nginx Pod 的新連線。 將立即接受來自具有 run=access 標籤之 Pod 的連線，這表示不會評估任何其他原則。
   • 如果連線來自沒有 run=access 標籤的 Pod (或來自任何不是 Pod 的 Pod)，則該 Kubernetes NetworkPolicy 不會執行任何動作，且 Calico 接下來會評估 log-denied-packets 原則。 此原則會將封包記載至 nginx Pod 所在工作者節點上的 syslog。
   • 然後，Calico 會檢查是否有任何其他原則套用至連線，因為它找不到任何原則，所以會捨棄封包。 這是因為已捨棄具有未明確容許之原則的 Pod 的任何資料流量。

       apiVersion: projectcalico.org/v3
       kind: NetworkPolicy
       metadata:
         name: log-denied-packets
       spec:
         types:
         - Ingress
         ingress:
         - action: Log
           destination: {}
           source: {}
         selector: projectcalico.org/orchestrator == 'k8s' && run == 'nginx'
         order: 3000
       ```
   
   

types

此 Ingress 政策適用於所有傳入的流量請求。 值「Ingress」是所有傳入流量的統稱，並非僅指來自 IBM Ingress ALB 的流量。| ingress : action: 「 Log 」動作會針對任何符合此政策的請求，將日誌條目寫入工作節點上的 /var/log/syslog 路徑中。 : destination: 由於 selector 會將此政策套用至所有具有特定標籤的 Pod，因此未指定目標。 : source: 本政策適用於來自任何來源的請求。

selector

選取器應該將與原始 access-nginx Kubernetes NetworkPolicy相同的資料流量設為目標。 由於這是 Calico 原則，因此您必須包括 projectcalico.org/orchestrator == 'k8s'，以指出除了原始 run == 'nginx' 之外，它還會套用至原則名稱空間中的所有 Pod。

order

Calico 原則含有順序可判定其何時套用至送入的要求封包。 優先級較低的政策（例如 1000 ）會優先套用。 會在較低順序的原則之後套用較高順序的原則。 舉例來說，一項序數極高的策略（例如 3000 ），會在所有序數較低的策略都已套用完畢後，才實際被最後套用。 送入的要求封包會經過 Iptables 規則鏈，並嘗試先符合較低順序原則的規則。 如果封包符合任何規則，則接受封包。 不過，如果封包不符合任何規則，它會抵達 Iptables 規則鏈中具有最高順序的最後一個規則。 為了確保此政策是鏈中的最後一項政策，請使用比步驟 1 中所建立的政策高得多的順序，例如 3000。 請注意，Kubernetes NetworkPolicy 會套用為訂單 1000。

3. 套用原則。 如果您使用 Windows 機器，請包含 --config=<filepath>/calicoctl.cfg 選項。

   calicoctl apply -f log-denied-packets.yaml [--config=<filepath>/calicoctl.cfg]
   

4. 透過傳送您在步驟 1 中建立的原則不容許的要求來產生日誌項目。 例如，嘗試從不允許的 Pod 或 IP 位址對受網路原則保護的 Pod 進行連線測試。

5. 檢查寫入 /var/log/syslog 路徑的日誌項目。 由於 Proxy、網址轉換 (NAT) 和其他網路處理程序，日誌項目中的 DST（目的地）或 SRC（來源）IP 位址可能不同於預期值。 日誌項目會與下列內容類似。

   Sep 5 14:34:40 <worker_hostname> kernel: [158271.044316] calico-packet: IN=eth1 OUT= MAC=08:00:27:d5:4e:57:0a:00:27:00:00:00:08:00 SRC=192.XXX.XX.X DST=192.XXX.XX.XX LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=52866 DF PROTO=TCP SPT=42962 DPT=22 WINDOW=29200 RES=0x00 SYN URGP=0
   

6. 選用：將日誌從 /var/log/syslog 轉遞到 IBM Cloud Logs 或外部 syslog 伺服器。