修复 EKS 防护调查发现 - Amazon GuardDuty
可能的配置问题修复可能失陷的 Kubernetes 用户修复可能失陷的 Kubernetes 容器组（pod）修复可能失陷的容器映像修复可能失陷的 Kubernetes 节点

修复 EKS 防护调查发现

为账户启用 EKS 防护后，Amazon 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 用户

如果调查发现中识别的用户执行了意外的 API 操作，GuardDuty 调查发现会指出 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 管理员的访问权限：

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

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

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

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

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

要撤销 AWS ConfigMap 用户的访问权限：

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

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

  2. 在 mapRoles 或 mapUsers 部分识别角色或用户条目，其用户名与 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

  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. 查看我的 AWS 账户可能被盗用中的信息，了解更多详情。

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

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

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

  1. 轮换服务账户凭证。

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

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

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

单个容器组盗用

如果 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 部分识别服务账户，则使用已识别服务账户的容器组可能被盗用。如果调查发现报告的用户名具有以下格式，则该用户名为服务账户：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。

修复可能失陷的容器组：

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

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

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

    有关更多信息，请参阅《Amazon EKS Best Practices Guide》中的 Redeploy compromised pod or workload resource。

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

修复可能失陷的容器映像

当 GuardDuty 调查发现表明某个容器组失陷，用于启动该容器组的映像可能有恶意或已失陷。GuardDuty 调查发现可识别 resource.kubernetesDetails.kubernetesWorkloadDetails.containers.image 字段中的容器映像。您可以通过扫描恶意软件来确定映像是否是恶意的。

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

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

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

    有关更多信息，请参阅《Amazon EKS Best Practices Guide》中的 Identify pods with vulnerable or compromised images and worker nodes。

  3. 隔离可能失陷的容器组、轮换凭证并收集数据进行分析。有关更多信息，请参阅《Amazon EKS Best Practices Guide》中的 Isolate the pod by creating a network policy that denies all ingress and egress traffic to the pod。

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

修复可能失陷的 Kubernetes 节点

如果 GuardDuty 调查发现中识别的用户代表节点身份，或者调查发现表明使用特权容器，则 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。

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

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