潛在的組態問題修復可能遭到入侵的 Kubernetes 使用者修復可能遭到入侵的 Kubernetes Pod 修復可能遭到入侵的容器映像修復可能遭到入侵的 Kubernetes 節點

修復EKS保護問題清單

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

如果預期會產生任何EKS保護問題清單類型，您可以考慮新增中的隱藏規則 GuardDuty以防止未來的提醒。

不同類型的攻擊和組態問題可能會觸發 GuardDuty EKS保護調查結果。本指南可協助您識別叢集 GuardDuty 問題清單的根本原因，並概述適當的修補指導。以下是導致 Kubernetes GuardDuty 問題清單的主要根本原因：

潛在的組態問題
修復可能遭到入侵的 Kubernetes 使用者
修復可能遭到入侵的 Kubernetes Pod
修復可能遭到入侵的 Kubernetes 節點
修復可能遭到入侵的容器映像

注意

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

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

潛在的組態問題

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

Policy:Kubernetes/AnonymousAccessGranted
Policy:Kubernetes/ExposedDashboard
Policy:Kubernetes/AdminAccessToDefaultServiceAccount
Policy:Kubernetes/KubeflowDashboardExposed
結尾為的任何問題清單 SuccessfulAnonymousAccess

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

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

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

注意

您可以使用 Amazon Detective 進一步調查調查結果中識別IAM的角色或使用者。在 GuardDuty 主控台中檢視問題清單詳細資訊時，選擇在 Detective 中調查。然後從列出的項目中選取 AWS 使用者或角色，以在 Detective 中進行調查。

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

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

識別 Access Key details 區段中的 userType。
- 如果 userType是角色，且該角色屬於EC2執行個體角色：
  - 識別該執行個體，然後按照修復可能遭到入侵的 Amazon EC2執行個體中的說明進行操作。
- 如果 userType 是使用者，或是使用者擔任的角色：
  1. 輪換該使用者的存取金鑰。
  2. 輪換使用者可存取的任何秘密。
  3. 檢閱 My 中的資訊 AWS 帳戶可能會遭到入侵，以取得更多詳細資訊。

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

若要撤銷已OIDC驗證使用者的存取權：

在OIDC提供者中輪換該使用者的登入資料。
輪換使用者可存取的任何秘密。

AWS-Auth ConfigMap 定義的使用者 – 透過 AWS身分驗證授予存取權IAM的使用者 ConfigMap。如需詳細資訊，請參閱 &EKS；使用者指南中的管理叢集的使用者或IAM角色。您可以使用以下命令檢視其許可：kubectl edit configmaps aws-auth --namespace kube-system

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

使用下列命令來開啟 ConfigMap。


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

識別或 mapUsers區段下的角色mapRoles或使用者項目，其使用者名稱與問題 GuardDuty 清單的 Kubernetes 使用者詳細資訊區段中回報的使用者名稱相同。請參閱下列範例，其中已在調查結果中識別管理員使用者。


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

從中移除該使用者 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

如果 userType 是使用者，或是使用者擔任的角色：
1. 輪換該使用者的存取金鑰。
2. 輪換使用者可存取的任何秘密。
3. 檢閱我的 AWS 帳戶中的資訊可能會遭到入侵，以取得更多詳細資訊。

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

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

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

輪換服務帳戶憑證。
檢閱下一節中有關 Pod 入侵的指引。

修復可能遭到入侵的 Kubernetes Pod

當在 resource.kubernetesDetails.kubernetesWorkloadDetails區段中 GuardDuty 指定 Pod 或工作負載資源的詳細資訊時，該 Pod 或工作負載資源可能會遭到入侵。 GuardDuty 調查結果可能表示單一 Pod 已遭入侵，或多個 Pod 已遭較高層級的資源入侵。如需有關如何識別遭到入侵的 Pod 的指引，請參閱下列入侵情況。

單一 Pod 入侵

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

如需識別執行 Pod 的工作者節點的相關資訊，請參閱識別違規的 Pod 和工作者節點。

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

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

如需識別工作負載資源的所有 Pod 及其執行節點的資訊，請參閱使用工作負載名稱識別違規的 Pod 和工作者節點。

透過服務帳戶入侵的 Pod

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

如需使用服務帳戶及其執行節點識別所有 Pod 的資訊，請參閱使用服務帳戶名稱識別違規的 Pod 和工作者節點。

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

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

識別入侵 Pod 的漏洞。
實作該漏洞的修正程式，並啟動新的替換 Pod。
刪除易遭受攻擊的 Pod。

如需詳細資訊，請參閱重新部署遭入侵的 Pod 或工作負載資源。

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

修復可能遭到入侵的容器映像

當 GuardDuty 問題清單指出 Pod 入侵時，用於啟動 Pod 的映像可能會惡意或遭到入侵。問題 GuardDuty 清單會識別 resource.kubernetesDetails.kubernetesWorkloadDetails.containers.image 欄位內的容器映像。您可以掃描映像是否含有惡意軟體，判斷該映像是否為惡意的。

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

立即停止使用該映像，並將其從映像儲存庫中移除。
使用可能遭到入侵的映像來識別所有 Pod。

如需詳細資訊，請參閱識別具有潛在易受攻擊或遭入侵容器映像和工作者節點的 Pod。
隔離可能遭到入侵的 Pod、輪換登入資料，以及收集資料進行分析。如需詳細資訊，請參閱 Amazon EKS最佳實務指南。
使用可能遭到入侵的映像刪除所有 Pod。

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

如果 GuardDuty 調查結果中識別的使用者代表節點身分，或調查結果指出使用特殊權限容器，則調查結果可能表示節點遭到入侵。

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

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

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

隔離 Pod、輪換其登入資料，並收集資料以進行鑑識分析。

如需詳細資訊，請參閱 Amazon EKS最佳實務指南。
識別在可能遭入侵的節點上執行的所有 Pod 所使用的服務帳戶。檢閱其許可，並視需要輪換服務帳戶。
終止可能遭到入侵的節點。

您的瀏覽器已停用或無法使用 Javascript。

您必須啟用 Javascript，才能使用 AWS 文件。請參閱您的瀏覽器說明頁以取得說明。

文件慣用形式

修復可能遭到入侵的獨立容器

修復執行期監控調查結果