修復 EKS 稽核日誌監控調查結果

當您的帳戶啟用 EKS 稽核日誌監控時，Amazon GuardDuty 會產生指出潛在 Kubernetes 安全問題的發現結果。如需詳細資訊，請參閱 EKS 稽核日誌監控。以下各節說明這些情況下的建議修復步驟。特定修復動作會在該特定調查結果類型的項目中說明。您可以從作用中調查結果類型表格中選取調查結果類型，以存取該類型的相關完整資訊。

如果任何 EKS 稽核日誌監控調查結果類型已如預期產生，您可以考慮新增 隱藏規則 以防止將來出現提醒。

不同類型的攻擊和設定問題可能會觸發 GuardDuty Kubernetes 發現項目。本指南可協助您針對叢集識別 GuardDuty 發現項目的根本原因，並概述適當的修復指引。以下是導致 GuardDuty Kubernetes 發現項目的主要根本原因：

• 潛在的組態問題

• 修復可能遭到入侵的 Kubernetes 使用者

• 修復可能遭到入侵的 Kubernetes 網繭

• 修復可能遭到入侵的 Kubernetes 節點

• 修復可能遭到破壞的容器映像

注意

在 Kubernetes 版本 1.14 之前，依預設，system:unauthenticated群組已與 () 相關聯。system:discovery system:basic-user ClusterRoles這可能會允許匿名使用者的意外存取。叢集更新不會撤銷這些許可，這表示即使您已將叢集更新至 1.14 版或更新版本，這些許可也許仍然存在。建議您取消這些許可與 system:unauthenticated 群組的關聯。

如需移除這些許可的詳細資訊，請參閱 Amazon EKS 使用者指南中的 Amazon EKS 安全最佳實務。

潛在的組態問題

如果調查結果指出組態問題，請參閱該調查結果的「修復」區段，以取得有關解決該特定問題的指引。如需詳細資訊，請參閱下列指出組態問題的調查結果類型：

• Policy:Kubernetes/AnonymousAccessGranted

• Policy:Kubernetes/ExposedDashboard

• Policy:Kubernetes/AdminAccessToDefaultServiceAccount

• Policy:Kubernetes/KubeflowDashboardExposed

• 任何結束的發現 SuccessfulAnonymousAccess

修復可能遭到入侵的 Kubernetes 使用者

當發 GuardDuty 現項目中識別的使用者執行非預期的 API 動作時，發現項目可能表示遭到入侵的 Kubernetes 使用者。您可以在主控台中調查結果詳細資訊的 Kubernetes 使用者詳細資訊區段中，或在調查結果 JSON 的 resources.eksClusterDetails.kubernetesDetails.kubernetesUserDetails 中識別使用者。這些使用者詳細資訊包括 user name、uid 和使用者所屬的 Kubernetes 群組。

如果使用者使用 IAM 實體存取工作負載，您可以使用 Access Key details 區段來識別 IAM 角色或使用者的詳細資訊。請參閱下列使用者類型及其修复指引。

注意

您可以使用 Amazon Detective 進一步調查調查結果中識別的 IAM 角色或使用者。在 GuardDuty 主控台中檢視發現項目詳細資料時，選擇 [Detective 中調查]。然後從列出的項目中選擇 AWS 用戶或角色以在「Detective」中對其進行調查。

內建的 Kubernetes 管理員：Amazon EKS 指派給建立叢集的 IAM 身分的預設使用者。此使用者類型由使用者名稱 kubernetes-admin 識別。

若要撤銷內建的 Kubernetes 管理員的存取權限：

• 識別 Access Key details 區段中的 userType。

  • 如果 userType 是角色且角色屬於 EC2 執行個體角色：

    • 識別該執行個體，然後按照 修復可能遭到入侵的 Amazon EC2 執行個體 中的說明進行操作。

  • 如果 userType 是使用者，或是使用者擔任的角色：

    1. 輪換該使用者的存取金鑰。

    2. 輪換使用者可存取的任何秘密。

    3. 查看「我的 AWS 帳戶」中的資訊可能會遭到入侵，以取得更多詳細

OIDC 驗證的使用者：透過 OIDC 提供者經授予存取權限的使用者。OIDC 使用者通常會以電子郵件地址作為使用者名稱。您可用下列命令檢查您的叢集是否使用 OIDC：aws eks list-identity-provider-configs --cluster-name your-cluster-name

撤銷 OIDC 驗證使用者的存取權限：

1. 在 OIDC 提供者中輪換該使用者的憑證。

2. 輪換使用者可存取的任何秘密。

AWS-身份驗證 ConfigMap 定義的用戶 — 通過 AWS- ConfigMap auth 授予訪問權限的 IAM 用戶。如需詳細資訊，請參閱《EKS 使用者指南》中的管理叢集的使用者或 IAM 角色。您可以使用以下命令檢視其許可：kubectl edit configmaps aws-auth --namespace kube-system

若要撤銷使 AWS ConfigMap用者的存取權：

1. 使用下列指令來開啟 ConfigMap。

   kubectl edit configmaps aws-auth --namespace kube-system

2. 使用與發現項目的 Kubernetes 使用者詳細資料區段中報告的使用者名稱相同的使用者名稱，識別「Map Rles」或「對應使用者」區段下的角色或使用者項目。 GuardDuty 請參閱下列範例，其中已在調查結果中識別管理員使用者。

   apiVersion: v1
   data:
     mapRoles: |
       - rolearn: arn:aws:iam::444455556666:role/eksctl-my-cluster-nodegroup-standard-wo-NodeInstanceRole-1WP3NUE3O6UCF
         user name: system:node:EC2_PrivateDNSName
         groups:
           - system:bootstrappers
           - system:nodes
     mapUsers: |
       - userarn: arn:aws:iam::123456789012:user/admin
         username: admin
         groups:
           - system:masters
       - userarn: arn:aws:iam::111122223333:user/ops-user
         username: ops-user
         groups:
           - system:masters

3. 從中移除該使用者 ConfigMap。請參閱下列範例，其中已移除管理員使用者。

   apiVersion: v1
   data:
     mapRoles: |
       - rolearn: arn:aws:iam::111122223333:role/eksctl-my-cluster-nodegroup-standard-wo-NodeInstanceRole-1WP3NUE3O6UCF
         username: system:node:{{EC2PrivateDNSName}}
         groups:
           - system:bootstrappers
           - system:nodes
     mapUsers: |
       - userarn: arn:aws:iam::111122223333:user/ops-user
         username: ops-user
         groups:
           - system:masters

4. 如果 userType 是使用者，或是使用者擔任的角色：

   1. 輪換該使用者的存取金鑰。

   2. 輪換使用者可存取的任何秘密。

   3. 查看「我的 AWS 帳戶」中的資訊可能會遭到入侵，以取得更多詳細

如果調查結果沒有 resource.accessKeyDetails 區段，則使用者是 Kubernetes 服務帳戶。

服務帳戶：服務帳戶提供 Pod 的身分，並可使用下列格式的使用者名稱進行識別：system:serviceaccount:namespace:service_account_name。

撤銷對服務帳戶的存取權限：

1. 輪換服務帳戶憑證。

2. 檢閱下一節中有關 Pod 入侵的指引。

修復可能遭到入侵的 Kubernetes 網繭

在resource.kubernetesDetails.kubernetesWorkloadDetails區段內 GuardDuty 指定網繭或工作負載資源的詳細資料時，該網繭或工作負載資源已可能遭到入侵。 GuardDuty 發現可能表示單一網繭已遭入侵，或是多個網繭已透過較高層級的資源遭到入侵。如需有關如何識別遭到入侵的 Pod 的指引，請參閱下列入侵情況。

單一 Pod 入侵

如果 resource.kubernetesDetails.kubernetesWorkloadDetails 區段內的 type 欄位是 Pod，則調查結果會識別單一 Pod。名稱欄位是 Pod 的 name，而 namespace 欄位則是其命名空間。

如需識別執行網繭之工作者節點的相關資訊，請參閱識別有問題的網繭和 Worker 節點。

Pod 透過工作負載資源遭到入侵

如果 resource.kubernetesDetails.kubernetesWorkloadDetails 區段內的 type 欄位識別出工作負載資源 (例如 Deployment)，則該工作負載資源中的所有 Pod 很可能都已遭到入侵。

如需識別工作負載資源的所有網繭及其執行所在節點的相關資訊，請參閱使用工作負載名稱識別有問題的網繭和 Worker 節點。

透過服務帳戶入侵的 Pod

如果發現項目在resource.kubernetesDetails.kubernetesUserDetails區段中識別了服務帳戶，則使用已識別服務帳戶的網繭很可能遭 GuardDuty 到入侵。如果調查結果報告的使用者名稱具有以下格式，則該使用者名稱是服務帳戶：system:serviceaccount:namespace:service_account_name。

如需使用服務帳戶及其執行所在節點識別所有網繭的相關資訊，請參閱使用服務帳戶名稱識別有問題的網繭和 Worker 節點。

識別出所有遭入侵的網繭及其執行所在的節點之後，請參閱 Amazon EKS 最佳實務指南，瞭解隔離網繭、輪換其登入資料，以及收集資料以進行鑑識分析。

若要修復可能遭到入侵的網繭：

1. 識別入侵 Pod 的漏洞。

2. 實作該漏洞的修正程式，並啟動新的替換 Pod。

3. 刪除易遭受攻擊的 Pod。

   如需詳細資訊，請參閱重新部署受損的網繭或工作負載資源。

如果已指派工作者節點的 IAM 角色可讓 Pod 取得其他 AWS 資源的存取權，請從執行個體中移除這些角色，以避免遭受進一步的攻擊損害。同樣地，如果已為 Pod 指派 IAM 角色，請評估您是否可以安全地從該角色中移除 IAM 政策，而不會影響其他工作負載。

修復可能遭到破壞的容器映像

當發 GuardDuty 現項目指出網繭入侵時，用來啟動網繭的映像可能是惡意或遭到入侵。 GuardDuty 發現項目會識別resource.kubernetesDetails.kubernetesWorkloadDetails.containers.image欄位內的容器映像。您可以掃描映像是否含有惡意軟體，判斷該映像是否為惡意的。

若要修復可能遭到入侵的容器映像檔：

1. 立即停止使用該映像，並將其從映像儲存庫中移除。

2. 使用可能遭到入侵的映像識別所有網繭。

   如需詳細資訊，請參閱識別具有可能易受攻擊或遭入侵之容器映像的網繭和背景工作

3. 隔離可能遭到入侵的 Pod、輪換憑證，並收集資料以進行分析。如需詳細資訊，請參閱 Amazon EKS 最佳實務指南。

4. 使用可能遭到入侵的映像刪除所有網繭。

修復可能遭到入侵的 Kubernetes 節點

如果發 GuardDuty 現項目中識別的使用者代表節點識別碼，或發現項目指出使用授權的容器，則發現項目可表示節點遭到入侵。

如果使用者名稱欄位具有以下格式，則使用者身分為工作節點：system:node:node name。例如 system:node:ip-192-168-3-201.ec2.internal。這表示對手已取得節點的存取權，而且正在使用節點的憑證與 Kubernetes API 端點通訊。

如果調查結果中列出的一個或多個容器的 resource.kubernetesDetails.kubernetesWorkloadDetails.containers.securityContext.privileged 調查結果欄位設定為 True，則該調查結果表示使用了有權限的容器。

若要修復可能遭到入侵的節點：

1. 隔離網繭、旋轉其認證，並收集資料以進行鑑識分析。

   如需詳細資訊，請參閱 Amazon EKS 最佳實務指南。

2. 識別可能遭到入侵的節點上執行的所有網繭所使用的服務帳戶。檢閱其許可，並視需要輪換服務帳戶。

3. 終止可能遭到入侵的節點。