修复 EKS 防护调查发现 - Amazon GuardDuty
可能的配置问题修复可能失陷的 Kubernetes 用户修复可能失陷的 Kubernetes 容器组（pod）修复可能失陷的容器映像修复可能失陷的 Kubernetes 节点
Amazon Web Services 文档中描述的 Amazon Web Services 服务或功能可能因区域而异。要查看适用于中国区域的差异，请参阅 中国的 Amazon Web Services 服务入门 (PDF)。

本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

修复 EKS 防护调查发现

当您的账户启用 EKS 保护时，Amazon GuardDuty 会生成发现潜在的 Kubernetes 安全问题。有关更多信息，请参阅 EKS 保护。以下各节介绍了针对这些场景的建议修复步骤。该特定调查发现类型的条目中描述了具体的修复措施。您可以从活动调查发现类型表中选择某一调查发现类型，即可获取该类型的完整信息。

如果生成的任何 EKS 防护调查发现类型符合预期，可以考虑添加 中的禁止规则 GuardDuty来阻止未来发出警报。

不同类型的攻击和配置问题可能会触发 GuardDuty EKS Protection 发现。本指南可帮助您确定针对您的集群的 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 控制台中查看发现的详细信息时，选择 “在 Det ective 中进行调查”。然后从列出的项目中选择 Amazon 用户或角色，在 Detective 中进行调查。

内置 Kubernetes 管理员：Amazon EKS 分配给创建集群的 IAM 身份的默认用户。此用户类型由用户名 kubernetes-admin 标识。

要撤销内置 Kubernetes 管理员的访问权限：

OIDC 验证的用户：通过 OIDC 提供程序授予访问权限的用户。通常，OIDC 用户使用电子邮件地址作为用户名。您可以使用以下命令查看您的集群是否使用 OIDC：aws eks list-identity-provider-configs --cluster-name your-cluster-name

要撤销 OIDC 验证的用户的访问权限：

  1. 在 OIDC 提供程序中轮换该用户的凭证。

  2. 轮换用户有权访问的任何密钥。

Amazon-Auth ConfigMap 定义的用户 — 通过-auth 被授予访问权限的 IAM 用户。 Amazon ConfigMap有关更多信息，请参阅 EKS 用户指南中的管理集群的用户或 IAM 角色。您可以使用以下命令查看其权限：kubectl edit configmaps aws-auth --namespace kube-system

要撤消 Amazon ConfigMap用户的访问权限，请执行以下操作：

  1. 使用以下命令打开 ConfigMap。

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

  2. 标识 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

  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. 查看 “我的 Amazon 账户可能被泄露” 中的信息，了解更多详情。

如果调查发现没有 resource.accessKeyDetails 部分，则用户是 Kubernetes 服务账户。

服务账户：服务账户为容器组提供身份，可以通过以下格式的用户名进行识别：system:serviceaccount:namespace:service_account_name。

要撤销对服务账户的访问权限：

  1. 轮换服务账户凭证。

  2. 在以下部分查看有关容器组受攻击的指南。

修复可能失陷的 Kubernetes 容器组（pod）

当在该resource.kubernetesDetails.kubernetesWorkloadDetails部分中 GuardDuty 指定 pod 或工作负载资源的详细信息时，该 pod 或工作负载资源可能已遭到破坏。 GuardDuty 发现可能表明单个 Pod 已被入侵，或者多个 Pod 已通过更高级别的资源遭到入侵。有关如何识别已被盗用的一个或多个容器组的指南，请参阅以下盗用场景。

单个容器组盗用

如果 resource.kubernetesDetails.kubernetesWorkloadDetails 部分中的 type 字段是容器组，则调查发现将识别单个容器组。名称字段是容器组的 name，namespace 字段是其命名空间。

有关识别运行容器组的 Worker 节点的信息，请参阅 Identify the offending pods and worker node。

容器组通过工作负载资源被盗用

如果 resource.kubernetesDetails.kubernetesWorkloadDetails 部分中的 type 字段识别工作负载资源（例如 Deployment），则该工作负载资源中的所有容器组很可能都已被盗用。

有关识别工作负载资源的所有容器组及其运行的节点的信息，请参阅 Identify the offending pods and worker nodes using workload name。

容器组通过服务账户被盗用

如果调查结果在该resource.kubernetesDetails.kubernetesUserDetails部分中 GuardDuty 发现了服务帐户，则使用已识别服务帐户的 pod 很可能遭到入侵。如果调查发现报告的用户名具有以下格式，则该用户名为服务账户：system:serviceaccount:namespace:service_account_name。

识别所有失陷的容器组及其运行的节点后，请参阅 Amazon EKS best practices guide 以隔离容器组，轮换其凭证，并收集数据以进行取证分析。

修复可能失陷的容器组：

  1. 识别攻击容器组的漏洞。

  2. 实施针对该漏洞的修复程序并启动新的替换容器组。

  3. 删除易受攻击的容器组。

    有关更多信息，请参阅 Redeploy compromised pod or workload resource。

如果已为工作节点分配了一个允许 Pod 访问其他 Amazon 资源的 IAM 角色，请将这些角色从实例中移除，以防止攻击造成进一步损害。同样，如果已为容器组分配了 IAM 角色，请评估您是否可以在不影响其他工作负载的情况下，从该角色安全删除 IAM 策略。

修复可能失陷的容器映像

当 GuardDuty 发现发现有 pod 受损时，用于启动 pod 的图像可能是恶意的或已被泄露的。 GuardDuty 调查结果可识别resource.kubernetesDetails.kubernetesWorkloadDetails.containers.image现场内的容器映像。您可以通过扫描恶意软件来确定映像是否是恶意的。

修复可能失陷的容器映像：

  1. 立即停止使用该映像，并将其从映像存储库中删除。

  2. 识别使用可能失陷的映像的所有容器组。

    有关更多信息，请参阅 Identify pods with potentially vulnerable or compromised container images and worker nodes。

  3. 隔离可能失陷的容器组、轮换凭证并收集数据进行分析。有关更多信息，请参阅 Amazon EKS best practices guide。

  4. 删除使用可能失陷的映像的所有容器组。

修复可能失陷的 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。

  2. 识别在可能失陷的节点上运行的所有容器组使用的服务账户。查看其权限，并根据需要轮换服务账户。

  3. 终止可能失陷的节点。