本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
# 修復 EKS 保護調查結果
當您的帳戶啟用 EKS 保護時，Amazon GuardDuty 會產生問題[清單](guardduty_findings.md)，指出潛在的 Kubernetes 安全問題。如需詳細資訊，請參閱[EKS 保護](kubernetes-protection.md)。以下各節說明這些情況下的建議修復步驟。特定修復動作會在該特定調查結果類型的項目中說明。您可以從[作用中調查結果類型表格](guardduty_finding-types-active.md)中選取調查結果類型，以存取該類型的相關完整資訊。
如果預期會產生任何 EKS 保護調查結果類型，您可以考慮新增 [GuardDuty 中的隱藏規則](findings_suppression-rule.md)以防止未來的提醒。
不同類型的攻擊和組態問題可能會觸發 GuardDuty EKS 保護調查結果。本指南可協助您針對叢集識別 GuardDuty 調查結果的根本原因，並概述適當的修復指引。以下是導致 GuardDuty Kubernetes 調查結果的主要根本原因：
+ [潛在的組態問題](#compromised-kubernetes-config)
+ [修復可能遭到入侵的 Kubernetes 使用者](#compromised-kubernetes-user)
+ [修復可能遭到入侵的 Kubernetes Pod](#compromised-kubernetes-pod)
+ [修復可能遭到入侵的 Kubernetes 節點](#compromised-kubernetes-node)
+ [修復可能遭到入侵的容器映像](#compromised-kubernetes-image)
**注意**
在 Kubernetes 版本 1.14 之前，`system:unauthenticated` 群組預設與 `system:discovery` 和 `system:basic-user` **ClusterRoles**相關聯。這可能會允許匿名使用者的意外存取。叢集更新不會撤銷這些許可，這表示即使您已將叢集更新至 1.14 版或更新版本，這些許可也許仍然存在。建議您取消這些許可與 `system:unauthenticated` 群組的關聯。
如需移除這些許可的詳細資訊，請參閱《[Amazon EKS 使用者指南》中的使用最佳實務保護 Amazon EKS 叢集](https://docs.aws.amazon.com/eks/latest/userguide/security-best-practices.html)。 ****
## 潛在的組態問題
如果調查結果指出組態問題，請參閱該調查結果的「修復」區段，以取得有關解決該特定問題的指引。如需詳細資訊，請參閱下列指出組態問題的調查結果類型：
+ [Policy:Kubernetes/AnonymousAccessGranted](guardduty-finding-types-eks-audit-logs.md#policy-kubernetes-anonymousaccessgranted)
+ [Policy:Kubernetes/ExposedDashboard](guardduty-finding-types-eks-audit-logs.md#policy-kubernetes-exposeddashboard)
+ [Policy:Kubernetes/AdminAccessToDefaultServiceAccount](guardduty-finding-types-eks-audit-logs.md#policy-kubernetes-adminaccesstodefaultserviceaccount)
+ [Policy:Kubernetes/KubeflowDashboardExposed](guardduty-finding-types-eks-audit-logs.md#policy-kubernetes-kubeflowdashboardexposed)
+ 任何以 **SuccessfulAnonymousAccess** 結尾的問題清單
## 修復可能遭到入侵的 Kubernetes 使用者
GuardDuty 調查結果可表示當調查結果中識別的使用者執行非預期的 API 動作時，Kubernetes 使用者已遭到入侵。您可以在主控台中調查結果詳細資訊的 **Kubernetes 使用者詳細資訊**區段中，或在調查結果 JSON 的 `resource.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 執行個體](compromised-ec2.md) 中的說明進行操作。
+ 如果 `userType` 是**使用者**，或是使用者擔任的**角色**：
1. [輪換該使用者的存取金鑰](https://docs.aws.amazon.com//IAM/latest/UserGuide/id_credentials_access-keys.html#Using_RotateAccessKey)。
1. 輪換使用者可存取的任何秘密。
1. 檢閱 [My 中的資訊 AWS 帳戶 可能會遭到入侵](https://repost.aws/knowledge-center/potential-account-compromise)，以取得更多詳細資訊。
**OIDC 驗證的使用者**：透過 OIDC 提供者經授予存取權限的使用者。OIDC 使用者通常會以電子郵件地址作為使用者名稱。您可用下列命令檢查您的叢集是否使用 OIDC：`aws eks list-identity-provider-configs --cluster-name your-cluster-name `
**撤銷 OIDC 驗證使用者的存取權限：**
1. 在 OIDC 提供者中輪換該使用者的憑證。
1. 輪換使用者可存取的任何秘密。
**AWS-Auth ConfigMap 定義的使用者** – 透過 AWS身分驗證 ConfigMap 授予存取權的 IAM 使用者。如需詳細資訊，請參閱《**Amazon EKS 使用者指南*》中的*[管理叢集的使用者或 IAM 角色](https://docs.aws.amazon.com/eks/latest/userguide/add-user-role.html)。您可以使用以下命令檢視其許可：`kubectl edit configmaps aws-auth --namespace kube-system`
**若要撤銷 an AWS ConfigMap 使用者的存取權：**
1. 使用下列命令開啟 ConfigMap。
```
kubectl edit configmaps aws-auth --namespace kube-system
```
1. 使用與 GuardDuty 調查結果的 Kubernetes 使用者詳細資訊區段中報告的使用者名稱相同的使用者名稱，在 **mapRoles** 或 **mapUsers** 區段下識別角色或使用者項目。請參閱下列範例，其中已在調查結果中識別管理員使用者。
```
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
```
1. 從 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
```
1. 如果 `userType` 是**使用者**，或是使用者擔任的**角色**：
1. [輪換該使用者的存取金鑰](https://docs.aws.amazon.com//IAM/latest/UserGuide/id_credentials_access-keys.html#Using_RotateAccessKey)。
1. 輪換使用者可存取的任何秘密。
1. 檢閱[我的 AWS 帳戶中的資訊可能會遭到入侵](https://aws.amazon.com//premiumsupport/knowledge-center/potential-account-compromise/)，以取得更多詳細資訊。
如果調查結果沒有 `resource.accessKeyDetails` 區段，則使用者是 Kubernetes 服務帳戶。
**服務帳戶**：服務帳戶提供 Pod 的身分，並可使用下列格式的使用者名稱進行識別：`system:serviceaccount:namespace:service_account_name`。
**撤銷對服務帳戶的存取權限：**
1. 輪換服務帳戶憑證。
1. 檢閱下一節中有關 Pod 入侵的指引。
## 修復可能遭到入侵的 Kubernetes Pod
當 GuardDuty 在 `resource.kubernetesDetails.kubernetesWorkloadDetails`區段中指定 Pod 或工作負載資源的詳細資訊時，該 Pod 或工作負載資源可能會遭到入侵。GuardDuty 調查結果可表示單一 Pod 已遭到入侵，或是多個 Pod 已透過較高層級的資源遭到入侵。如需有關如何識別遭到入侵的 Pod 的指引，請參閱下列入侵情況。
**單一 Pod 入侵**
如果 `resource.kubernetesDetails.kubernetesWorkloadDetails` 區段內的 `type` 欄位是 **Pod**，則調查結果會識別單一 Pod。名稱欄位是 Pod 的 `name`，而 `namespace` 欄位則是其命名空間。
如需識別執行 Pod 的工作者節點的相關資訊，請參閱《*Amazon EKS 最佳實務指南*》中的[識別違規的 Pod 和工作者節點](https://docs.aws.amazon.com/eks/latest/best-practices/incident-response-and-forensics.html#_identify_the_offending_pod_and_worker_node)。
**Pod 透過工作負載資源遭到入侵**
如果 `resource.kubernetesDetails.kubernetesWorkloadDetails` 區段內的 `type` 欄位識別出**工作負載資源** (例如 `Deployment`)，則該工作負載資源中的所有 Pod 很可能都已遭到入侵。
如需有關識別工作負載資源的所有 Pod 及其執行節點的資訊，請參閱《*Amazon EKS 最佳實務指南*》中的[使用工作負載名稱識別違規的 Pod 和工作者節點](https://docs.aws.amazon.com/eks/latest/best-practices/incident-response-and-forensics.html#_identify_the_offending_pods_and_worker_nodes_using_workload_name)。
**透過服務帳戶入侵的 Pod**
如果 GuardDuty 調查結果在 `resource.kubernetesDetails.kubernetesUserDetails` 區段中識別出服務帳戶，則使用已識別服務帳戶的 Pod 很可能遭到入侵。如果調查結果報告的使用者名稱具有以下格式，則該使用者名稱是服務帳戶：`system:serviceaccount:namespace:service_account_name`。
如需使用服務帳戶及其執行節點識別所有 Pod 的資訊，請參閱《*Amazon EKS 最佳實務指南*》中的[使用服務帳戶名稱識別違規的 Pod 和工作者節點](https://docs.aws.amazon.com/eks/latest/best-practices/incident-response-and-forensics.html#_identify_the_offending_pods_and_worker_nodes_using_service_account_name)。
識別所有遭入侵的 Pod 及其執行節點之後，請參閱《*Amazon EKS 最佳實務指南*》中的[建立拒絕所有傳入和傳出流量的網路政策來隔離 Pod](https://docs.aws.amazon.com/eks/latest/best-practices/incident-response-and-forensics.html#_isolate_the_pod_by_creating_a_network_policy_that_denies_all_ingress_and_egress_traffic_to_the_pod)。
**若要修復可能遭到入侵的 Pod：**
1. 識別入侵 Pod 的漏洞。
1. 實作該漏洞的修正程式，並啟動新的替換 Pod。
1. 刪除易遭受攻擊的 Pod。
如需詳細資訊，請參閱《*Amazon EKS 最佳實務指南*》中的[重新部署遭入侵的 Pod 或工作負載資源](https://docs.aws.amazon.com/eks/latest/best-practices/incident-response-and-forensics.html#_redeploy_compromised_pod_or_workload_resource)。
如果工作者節點已指派允許 Pod 存取其他 AWS 資源的 IAM 角色，請從執行個體中移除這些角色，以防止進一步受到攻擊。同樣地，如果已為 Pod 指派 IAM 角色，請評估您是否可以安全地從該角色中移除 IAM 政策，而不會影響其他工作負載。
## 修復可能遭到入侵的容器映像
當 GuardDuty 調查結果指出 Pod 入侵時，用於啟動 Pod 的映像可能是惡意或入侵。GuardDuty 調查結果可識別 `resource.kubernetesDetails.kubernetesWorkloadDetails.containers.image` 欄位內的容器映像。您可以掃描映像是否含有惡意軟體，判斷該映像是否為惡意的。
**若要修復可能遭到入侵的容器映像：**
1. 立即停止使用該映像，並將其從映像儲存庫中移除。
1. 使用可能遭到入侵的映像來識別所有 Pod。
如需詳細資訊，請參閱《*Amazon EKS 最佳實務指南*》中的[識別具有易受攻擊或受損影像的 Pod 和工作者節點](https://docs.aws.amazon.com/eks/latest/best-practices/incident-response-and-forensics.html#_identify_pods_with_vulnerable_or_compromised_images_and_worker_nodes)。
1. 隔離可能遭到入侵的 Pod、輪換登入資料，以及收集資料進行分析。如需詳細資訊，請參閱《*Amazon EKS 最佳實務指南*[》中的建立拒絕所有輸入和輸出流量至 Pod 的網路政策來隔離 Pod](https://docs.aws.amazon.com/eks/latest/best-practices/incident-response-and-forensics.html#_isolate_the_pod_by_creating_a_network_policy_that_denies_all_ingress_and_egress_traffic_to_the_pod)。
1. 使用可能遭到入侵的映像刪除所有 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`，則該調查結果表示使用了有權限的容器。
**若要修復可能遭到入侵的節點：**
1. 隔離 Pod、輪換其登入資料，並收集資料以進行鑑識分析。
如需詳細資訊，請參閱《*Amazon EKS 最佳實務指南*[》中的建立拒絕所有輸入和輸出流量至 Pod 的網路政策來隔離 Pod](https://docs.aws.amazon.com/eks/latest/best-practices/incident-response-and-forensics.html#_isolate_the_pod_by_creating_a_network_policy_that_denies_all_ingress_and_egress_traffic_to_the_pod)。
1. 識別在可能遭到入侵的節點上執行的所有 Pod 所使用的服務帳戶。檢閱其許可，並視需要輪換服務帳戶。
1. 終止可能遭到入侵的節點。