修复发现的 Kubernetes 安全问题 GuardDuty - 亚马逊 GuardDuty
配置问题泄露的用户泄露的容器泄露的容器映像泄露的节点
Amazon Web Services 文档中描述的 Amazon Web Services 服务或功能可能因区域而异。要查看适用于中国区域的差异，请参阅 中国的 Amazon Web Services 服务入门 (PDF)。

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

修复发现的 Kubernetes 安全问题 GuardDuty

亚马逊 GuardDuty 生成的调查结果表明，在为您的账户启用 EK GuardDuty S 保护后，可能会出现 Kubernetes 安全问题。有关更多信息，请参阅亚马逊的 EKS 保护 GuardDuty：以下各节介绍这些场景的建议补救步骤。该特定发现类型的条目中描述了特定的补救措施。您可以通过从 “有效的查找结果类型” 表格中选择查找结果类型来访问有关该查找结果的完整信息。

不同类型的攻击和配置问题可能会触发 GuardDuty Kubernetes 的调查结果。本指南可帮助您确定针对集群的 GuardDuty 发现的根本原因，并概述了相应的补救指南。以下是导致 GuardDuty Kubernetes 发现的主要根本原因：

注意

在 Kubernetes 版本 1.14 之前，system:basic-userClusterRoles默认情况下，该system:unauthenticated群组与system:discovery和相关联。这可能允许匿名用户进行意外访问。集群更新不会撤消这些权限，这意味着即使您已将集群更新到版本 1.14 或更高版本，这些权限仍可能有效。我们建议您取消这些权限与system:unauthenticated群组的关联。有关删除这些权限的说明，请参阅查看和撤消不必要的匿名访问权限。

配置问题

如果某项发现表明存在配置问题，请参阅该调查结果的 “补救” 部分，以获取有关解决该特定问题的指导。有关更多信息，请参阅以下表明配置问题的查找类型：

修复受感染的 Kubernetes 用户

当 GuardDuty 发现中识别的用户执行了意外的 API 操作时，发现结果可以表明 Kubernetes 用户受到了威胁。您可以在控制台中查找详细信息的 Kubernetes 用户详细信息部分中识别用户，也可以在发现 JSON 中resources.eksClusterDetails.kubernetesDetails.kubernetesUserDetails识别用户。这些列user name出用户属于的组。uid

如果用户使用 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 定义的用户 — 通过Amazon-auth 获得访问权限的 IAM 用户 ConfigMap。有关更多信息，请参阅 &EKS; 用户指南中的管理集群的用户或 IAM 角色。您可以使用以下命令来查看他们的权限：kubectl edit configmaps aws-auth --namespace kube-system

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

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

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

  2. 识别 Map roles 或 Map Users 部分下的角色或用户条目，其用户名与 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. 查看 “我的Amazon账户可能被盗用” 中的信息，了解更多详情。

如果调查结果没有resource.accessKeyDetails章节，则用户是 Kubernetes 服务帐号。

服务帐号 — 服务帐号为 pod 提供身份，可通过以下格式的用户名进行识别:system:serviceaccount:namespace:service_account_name.

要撤消对服务帐号的访问权限，请执行以下操作：

  1. 轮换服务帐号凭证。

  2. 查看下一节中的 pod 入侵指南。

修复受损的 Kubernetes pod

当在该resource.kubernetesDetails.kubernetesWorkloadDetails部分中 GuardDuty 指定 pod 或工作负载资源的详细信息时，该 pod 或工作负载资源可能会受到威胁。一项 GuardDuty 发现可能表明单个 pod 已被入侵，或者多个 pod 已通过更高级别的资源遭到入侵。有关如何识别已被入侵的一个或多个吊舱的指导，请参阅以下入侵场景。

单个吊舱妥协

如果分resource.kubernetesDetails.kubernetesWorkloadDetails区内的type字段是 pod，则该发现会识别出单个 pod。名称字段是 podname 的，namespace字段是它的命名空间。使用 “识别违规 Pod 和工作节点” 中的说明来识别运行 Pod 的工作节点。

Pod 因工作负载资源而受损

如果该resource.kubernetesDetails.kubernetesWorkloadDetails部分内的type字段标识了工作负载资源，例如 aDeployment，则该工作负载资源中的所有 pod 很可能都已受到威胁。使用 “使用工作负载名称识别违规 Pod 和工作节点” 中的说明来识别工作负载资源的所有 Pod 及其正在运行的节点。

Pod 通过服务账号入侵

如果 GuardDuty 发现发现了该resource.kubernetesDetails.kubernetesUserDetails部分中的服务帐号，则很可能是使用已识别服务帐号的 pod 遭到入侵。如果发现结果报告的用户名具有以下格式，则该用户名是服务帐户:system:serviceaccount:namespace:service_account_name. 使用 “使用服务账户名识别违规 Pod 和工作节点” 中的说明，使用服务帐号识别所有 Pod 及其正在运行的节点。

确定所有受感染的 Pod 及其运行的节点后，使用 EKS 最佳实践指南中的以下说明隔离 Pod、轮换其凭证并收集用于取证分析的数据。

要修复受损的 pod，请执行以下操作：

  1. 找出危害 pod 的漏洞。

  2. 修复该漏洞并启动新的替换 pod。

  3. 删除有漏洞 Pod。有关更多信息，请参阅重新部署受损的 Pod 或工作负载资源。

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

修复泄露的容器映像

当 GuardDuty 发现表明 pod 遭到入侵时，用于启动 pod 的图像可能是恶意的或受损的。 GuardDuty 发现可识别resource.kubernetesDetails.kubernetesWorkloadDetails.containers.image现场内的容器映像。您可以通过扫描图像中是否存在恶意软件来确定该图像是否为恶意图像。

要修复受损的容器镜像，请执行以下操作：

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

  2. 使用图像识别所有豆荚。有关更多信息，请参阅识别具有易受攻击或受损容器映像的容器镜像和工作节点的 pod。

  3. 隔离受感染的 pod，轮换凭证并收集数据进行分析。有关更多信息，请参阅 EKS 最佳实践指南中的以下说明。

  4. 使用受损映像删除所有 pod。

修复受损的 Kubernetes 节点

如果 GuardDuty 发现结果中确定的用户代表节点身份，或者如果发现结果表明使用了特权容器，则发现结果可能表明节点存在危险。

如果用户名字段的格式如下，则用户身份为工作节点：system:node:node name。例如，system:node:ip-192-168-3-201.ec2.internal。这表明对手已经获得了对该节点的访问权限，并且正在使用该节点的证书与 Kubernetes API 端点通信。

如果查找结果中列出的一个或多个容器的查找字段设置为，则发现结果表示使用特权容器True。resource.kubernetesDetails.kubernetesWorkloadDetails.containers.securityContext.privileged

要修复受感染的节点，请执行以下操作：

  1. 使用 EKS 最佳实践指南中的说明隔离 Pod、轮换其凭证并收集用于取证分析的数据。

  2. 识别节点上运行的所有 Pod 使用的服务帐号。查看他们的权限，并在需要时轮换服务帐号。

  3. 终止节点。