本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。
# 修复 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 Protection 发现。本指南可帮助您确定针对您的集群的 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 控制台中查看发现的详细信息时，选择 “在 Det **ective 中进行调查**”。然后从列出的项目中选择 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. 查看 “[我的 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 定义的用户** — 通过-auth 获得访问权限的 IAM 用户。 AWS ConfigMap有关更多信息，请参阅****《Amazon EKS 用户指南》中的[管理集群的用户或 IAM 角色](https://docs.aws.amazon.com/eks/latest/userguide/add-user-role.html)。您可以使用以下命令查看其权限：`kubectl edit configmaps aws-auth --namespace kube-system`
**要撤消 AWS ConfigMap用户的访问权限，请执行以下操作：**
1. 使用以下命令打开 ConfigMap。
```
kubectl edit configmaps aws-auth --namespace kube-system
```
1. 标识 mapRo **les 或 M** **apUsers 部分下的角色或用户**条目，其用户名与调查结果的 Kubernetes 用户详细信息部分中报告的用户名相同。 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
```
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 服务账户。
**服务账户**：服务账户为容器组提供身份，可以通过以下格式的用户名进行识别：`system:serviceaccount:namespace:service_account_name`。
**要撤销对服务账户的访问权限：**
1. 轮换服务账户凭证。
1. 在以下部分查看有关容器组受攻击的指南。
## 修复可能失陷的 Kubernetes 容器组（pod）
当在该`resource.kubernetesDetails.kubernetesWorkloadDetails`部分中 GuardDuty 指定 pod 或工作负载资源的详细信息时，该 pod 或工作负载资源可能已受到威胁。 GuardDuty 发现可能表明单个 Pod 已被入侵，或者多个 Pod 已通过更高级别的资源遭到入侵。有关如何识别已被盗用的一个或多个容器组的指南，请参阅以下盗用场景。
**单个容器组盗用**
如果 `resource.kubernetesDetails.kubernetesWorkloadDetails` 部分中的 `type` 字段是**容器组**，则调查发现将识别单个容器组。名称字段是容器组的 `name`，`namespace` 字段是其命名空间。
有关识别运行容器组（pod）的 Worker 节点的信息，请参阅《Amazon EKS Best Practices Guide》**中的 [Identify the offending pods and worker node](https://docs.aws.amazon.com/eks/latest/best-practices/incident-response-and-forensics.html#_identify_the_offending_pod_and_worker_node)。
**容器组通过工作负载资源被盗用**
如果 `resource.kubernetesDetails.kubernetesWorkloadDetails` 部分中的 `type` 字段识别**工作负载资源**（例如 `Deployment`），则该工作负载资源中的所有容器组很可能都已被盗用。
有关识别工作负载资源的所有容器组（pod）及其运行的节点的信息，请参阅《Amazon EKS Best Practices Guide》**中的 [Identify the offending pods and worker nodes using workload name](https://docs.aws.amazon.com/eks/latest/best-practices/incident-response-and-forensics.html#_identify_the_offending_pods_and_worker_nodes_using_workload_name)。
**容器组通过服务账户被盗用**
如果调查结果在该`resource.kubernetesDetails.kubernetesUserDetails`部分中 GuardDuty 发现了服务帐户，则使用已识别服务帐户的 pod 很可能遭到入侵。如果调查发现报告的用户名具有以下格式，则该用户名为服务账户：`system:serviceaccount:namespace:service_account_name`。
有关识别使用服务账户的所有容器组（pod）及其运行的节点的信息，请参阅**《Amazon EKS Best Practices Guide》中的 [Identify the offending pods and worker nodes using service account name](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 Best Practices Guide》中的 [Isolate the pod by creating a network policy that denies all ingress and egress traffic to the 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. 识别攻击容器组的漏洞。
1. 实施针对该漏洞的修复程序并启动新的替换容器组。
1. 删除易受攻击的容器组。
有关更多信息，请参阅《Amazon EKS Best Practices Guide》**中的 [Redeploy compromised pod or workload resource](https://docs.aws.amazon.com/eks/latest/best-practices/incident-response-and-forensics.html#_redeploy_compromised_pod_or_workload_resource)。
如果已为工作节点分配了一个允许 Pod 访问其他 AWS 资源的 IAM 角色，请将这些角色从实例中移除，以防止攻击造成进一步损害。同样，如果已为容器组分配了 IAM 角色，请评估您是否可以在不影响其他工作负载的情况下，从该角色安全删除 IAM 策略。
## 修复可能失陷的容器映像
当 GuardDuty 发现发现有 pod 受损时，用于启动 pod 的图像可能是恶意的或已被泄露的。 GuardDuty 调查结果可识别`resource.kubernetesDetails.kubernetesWorkloadDetails.containers.image`现场内的容器映像。您可以通过扫描恶意软件来确定映像是否是恶意的。
**修复可能失陷的容器映像：**
1. 立即停止使用该映像，并将其从映像存储库中删除。
1. 识别使用可能失陷的映像的所有容器组。
有关更多信息，请参阅《Amazon EKS Best Practices Guide》**中的 [Identify pods with vulnerable or compromised images and worker nodes](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. 隔离可能失陷的容器组、轮换凭证并收集数据进行分析。有关更多信息，请参阅《Amazon EKS Best Practices Guide》中的 [Isolate the pod by creating a network policy that denies all ingress and egress traffic to the 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. 删除使用可能失陷的映像的所有容器组。
## 修复可能失陷的 Kubernetes 节点
如果 GuardDuty 发现结果中标识的用户代表节点身份，或者发现结果表明使用了特权容器，则发现可能表示节点受损。
如果**用户名**字段具有以下格式，则用户身份是 Worker 节点：`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 Best Practices Guide》中的 [Isolate the pod by creating a network policy that denies all ingress and egress traffic to the 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. 识别在可能失陷的节点上运行的所有容器组使用的服务账户。查看其权限，并根据需要轮换服务账户。
1. 终止可能失陷的节点。