本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。
修复 EKS 防护调查发现
当您的账户启用 EKS 保护时，亚马逊 GuardDuty 生成的调查结果表明潜在的 Kubernetes 安全问题。有关更多信息，请参阅 EKS 保护。以下各节介绍了针对这些场景的建议修复步骤。该特定调查发现类型的条目中描述了具体的修复措施。您可以从活动调查发现类型表中选择某一调查发现类型，即可获取该类型的完整信息。
如果生成的任何 EKS 防护调查发现类型符合预期，可以考虑添加 中的抑制规则 GuardDuty来阻止未来发出警报。
不同类型的攻击和配置问题可能会触发 GuardDuty EKS 保护发现。本指南可帮助您确定针对集群的 GuardDuty 发现的根本原因，并概述了相应的补救指南。以下是导致 GuardDuty Kubernetes 发现的主要根本原因：
注意
在 Kubernetes 版本 1.14 之前，该system:unauthenticated群组与默认关联且默认情况下是关联的。system:discovery system:basic-user ClusterRoles 此操作可能允许来自匿名用户的意外访问。集群更新不会撤销这些权限，这意味着即使您已将集群更新到 1.14 或更高版本，这些权限可能仍然存在。我们建议您取消这些权限与 system:unauthenticated 组的关联。
有关移除这些权限的更多信息，请参阅《Amazon EKS 用户指南》中的 使用最佳实践保护 Amazon EKS 集群。
可能的配置问题
如果调查发现表明存在配置问题，请参阅调查发现的修复部分，以获取有关解决该问题的指导。有关更多信息，请参阅以下指示配置问题的调查发现类型：
修复可能失陷的 Kubernetes 用户
当 GuardDuty 发现中识别的用户执行了意外的 API 操作时，发现可以表明该用户已被侵入 Kubernetes 用户。您可以在调查发现详细信息的 Kubernetes 用户详细信息部分（位于控制台），或调查发现 JSON 的 resource.kubernetesDetails.kubernetesUserDetails 中识别用户。这些用户详细信息包括 user name、uid 和用户所属的 Kubernetes 组。
如果用户使用 IAM 实体访问工作负载，则可以使用 Access Key details 部分来识别 IAM 角色或用户的详细信息。请参阅以下用户类型及其修复指南。
注意
您可以使用 Amazon Detective，以进一步调查调查发现中识别的 IAM 角色或用户。在 GuardDuty 主机中查看查找细节时，选择 “在侦探中调查” 。然后从列出的项目中选择 Amazon 用户或角色，在 Detective 中进行调查。
- Built-in Kubernetes 管理员 — 亚马逊 EKS 分配给创建集群的 IAM 身份的默认用户。此用户类型由用户名
kubernetes-admin标识。 -
要撤销内置 Kubernetes 管理员的访问权限：
-
从
Access Key details部分中识别userType。-
如果
userType是角色，并且该角色属于 EC2 实例角色：-
识别该实例，然后按照 修复可能失陷的 Amazon EC2 实例 中的说明操作。
-
-
如果
userType是用户，或者是用户承担的角色：-
轮换用户有权访问的任何密钥。
-
查看 “我的 Amazon Web Services 账户 可能会被泄露” 中的信息
以获取更多详细信息。
-
-
- OIDC 验证的用户：通过 OIDC 提供程序授予访问权限的用户。通常，OIDC 用户使用电子邮件地址作为用户名。您可以使用以下命令查看您的集群是否使用 OIDC：
aws eks list-identity-provider-configs --cluster-nameyour-cluster-name -
要撤销 OIDC 验证的用户的访问权限：
-
在 OIDC 提供程序中轮换该用户的凭证。
-
轮换用户有权访问的任何密钥。
-
- Amazon-Auth ConfigMap 定义用户 — 通过-auth 获得访问权限的 IAM 用户。 Amazon ConfigMap有关更多信息，请参阅《Amazon EKS 用户指南》中的管理集群的用户或 IAM 角色。您可以使用以下命令查看其权限：
kubectl edit configmaps aws-auth --namespace kube-system -
要撤消 Amazon ConfigMap用户的访问权限，请执行以下操作：
-
使用以下命令打开 ConfigMap。
kubectl edit configmaps aws-auth --namespace kube-system -
确定 mapRol es 或 MapUsers 部分下的角色或用户条目，其用户名应与发现结果的 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 -
将该用户从 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是用户，或者是用户承担的角色：-
轮换用户有权访问的任何密钥。
-
查看 “我的 Amazon 账户可能遭到泄露” 中的信息
，了解更多详情。
-
如果调查发现没有 resource.accessKeyDetails 部分，则用户是 Kubernetes 服务账户。
- 服务账户：服务账户为容器组提供身份，可以通过以下格式的用户名进行识别：
system:serviceaccount:。namespace:service_account_name -
要撤销对服务账户的访问权限：
-
轮换服务账户凭证。
-
在以下部分查看有关容器组受攻击的指南。
-
修复可能失陷的 Kubernetes 容器组（pod）
当在该resource.kubernetesDetails.kubernetesWorkloadDetails部分中 GuardDuty 指定 pod 或工作负载资源的详细信息时，该容器或工作负载资源可能已受到损害。 GuardDuty 发现可以表明单个 pod 已被入侵，或者多个 pod 已通过更高级别的资源遭到入侵。有关如何识别已被盗用的一个或多个容器组的指南，请参阅以下盗用场景。
- 单个容器组盗用
-
如果
resource.kubernetesDetails.kubernetesWorkloadDetails部分中的type字段是容器组，则调查发现将识别单个容器组。名称字段是容器组的name，namespace字段是其命名空间。有关识别运行容器组（pod）的 Worker 节点的信息，请参阅《Amazon EKS Best Practices Guide》中的 Identify the offending pods and worker node。
- 容器组通过工作负载资源被盗用
-
如果
resource.kubernetesDetails.kubernetesWorkloadDetails部分中的type字段识别工作负载资源（例如Deployment），则该工作负载资源中的所有容器组很可能都已被盗用。有关识别工作负载资源的所有容器组（pod）及其运行的节点的信息，请参阅《Amazon EKS Best Practices Guide》中的 Identify the offending pods and worker nodes using workload name。
- 容器组通过服务账户被盗用
-
如果 GuardDuty 发现该
resource.kubernetesDetails.kubernetesUserDetails部分中发现了服务帐号，则使用该服务帐号的 pod 很可能会遭到入侵。如果调查发现报告的用户名具有以下格式，则该用户名为服务账户：system:serviceaccount:。namespace:service_account_name有关识别使用服务账户的所有容器组（pod）及其运行的节点的信息，请参阅《Amazon EKS Best Practices Guide》中的 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。
修复可能失陷的容器组：
-
识别攻击容器组的漏洞。
-
实施针对该漏洞的修复程序并启动新的替换容器组。
-
删除易受攻击的容器组。
有关更多信息，请参阅《Amazon EKS Best Practices Guide》中的 Redeploy compromised pod or workload resource。
如果已为工作节点分配了一个允许 Pod 访问其他 Amazon 资源的 IAM 角色，则将这些角色从实例中移除，以防止攻击造成进一步损害。同样，如果已为容器组分配了 IAM 角色，请评估您是否可以在不影响其他工作负载的情况下，从该角色安全删除 IAM 策略。
修复可能失陷的容器映像
当 GuardDuty 发现表明 pod 遭到入侵时，用于启动 pod 的图像可能是恶意的或受损的。 GuardDuty 调查结果可识别resource.kubernetesDetails.kubernetesWorkloadDetails.containers.image字段内的容器映像。您可以通过扫描恶意软件来确定映像是否是恶意的。
修复可能失陷的容器映像：
-
立即停止使用该映像，并将其从映像存储库中删除。
-
识别使用可能失陷的映像的所有容器组。
有关更多信息，请参阅《Amazon EKS Best Practices Guide》中的 Identify pods with vulnerable or compromised images and worker nodes。
-
隔离可能失陷的容器组、轮换凭证并收集数据进行分析。有关更多信息，请参阅《Amazon EKS Best Practices Guide》中的 Isolate the pod by creating a network policy that denies all ingress and egress traffic to the pod。
-
删除使用可能失陷的映像的所有容器组。
修复可能失陷的 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，则调查发现表明使用了特权容器。
修复可能失陷的节点：
-
隔离容器组、轮换凭证并收集数据进行分析。
有关更多信息，请参阅《Amazon EKS Best Practices Guide》中的 Isolate the pod by creating a network policy that denies all ingress and egress traffic to the pod。
-
识别在可能失陷的节点上运行的所有容器组使用的服务账户。查看其权限，并根据需要轮换服务账户。
-
终止可能失陷的节点。