潜在的配置问题修复可能受到威胁的 Kubernetes 用户修复可能遭到入侵的 Kubernetes 吊舱修复可能受损的容器镜像修复可能受到威胁的 Kubernetes 节点

修复EKS保护发现

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

如果任何 Protection 查找类型是预期生成的，则可以考虑添加中的禁止规则 GuardDuty以EKS防将来出现警报。

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

潜在的配置问题
修复可能受到威胁的 Kubernetes 用户
修复可能遭到入侵的 Kubernetes 吊舱
修复可能受到威胁的 Kubernetes 节点
修复可能受损的容器镜像

注意

在 Kubernetes 版本 1.14 之前，该system:unauthenticated群组与默认关联且处于关联状态。system:discovery system:basic-user ClusterRoles此操作可能允许来自匿名用户的意外访问。集群更新不会撤销这些权限，这意味着即使您已将集群更新到 1.14 或更高版本，这些权限可能仍然存在。我们建议您取消这些权限与 system:unauthenticated 组的关联。

有关移除这些权限的更多信息，请参阅《亚马逊EKS用户指南》EKS中的亚马逊安全最佳实践。

潜在的配置问题

如果调查发现表明存在配置问题，请参阅调查发现的修复部分，以获取有关解决该问题的指导。有关更多信息，请参阅以下指示配置问题的调查发现类型：

Policy:Kubernetes/AnonymousAccessGranted
Policy:Kubernetes/ExposedDashboard
Policy:Kubernetes/AdminAccessToDefaultServiceAccount
Policy:Kubernetes/KubeflowDashboardExposed
任何以结尾的发现 SuccessfulAnonymousAccess

修复可能受到威胁的 Kubernetes 用户

当 GuardDuty 发现中识别的用户执行了意外操作时，发现可能表明 Kubernetes 用户受到了攻击。API你可以在控制台中查找结果详细信息的 Kubernetes 用户详细信息部分或调查结果中resources.eksClusterDetails.kubernetesDetails.kubernetesUserDetails识别用户。JSON这些用户详细信息包括 user name、uid 和用户所属的 Kubernetes 组。

如果用户使用IAM实体访问工作负载，则可以使用该Access Key details部分来标识IAM角色或用户的详细信息。请参阅以下用户类型及其修复指南。

注意

您可以使用 Amazon Detective 进一步调查调查结果中确定的IAM角色或用户。在 GuardDuty 控制台中查看发现的详细信息时，选择 “在 Det ective 中进行调查”。然后从列出的项目中选择 AWS 用户或角色在 Detective 中进行调查。

内@@ 置 Kubernetes 管理员 — 亚马逊EKS为创建集群的IAM身份分配的默认用户。此用户类型由用户名 kubernetes-admin 标识。

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

从 Access Key details 部分中识别 userType。
- 如果userType是角色并且该角色属于EC2实例角色：
  - 识别该实例，然后按照修复可能遭到入侵的 Amazon 实例 EC2 中的说明操作。
- 如果 userType 是用户，或者是用户承担的角色：
  1. 轮换该用户的访问密钥。
  2. 轮换用户有权访问的任何密钥。
  3. 查看 “我的 AWS 账户可能被泄露” 中的信息，了解更多详情。

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

要撤消OIDC经过身份验证的用户的访问权限，请执行以下操作：

在OIDC提供商中轮换该用户的证书。
轮换用户有权访问的任何密钥。

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

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

使用以下命令打开 ConfigMap。


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

找出或mapUsers部分下的角色或用户条目，其用户名与调查结果的 Kubernetes 用户详细信息部分中报告的用户名相同。mapRoles 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 是用户，或者是用户承担的角色：
1. 轮换该用户的访问密钥。
2. 轮换用户有权访问的任何密钥。
3. 查看 “我的 AWS 账户可能被泄露” 中的信息，了解更多详情。

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

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

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

轮换服务账户凭证。
在以下部分查看有关容器组受攻击的指南。

修复可能遭到入侵的 Kubernetes 吊舱

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

单个容器组盗用

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

有关识别运行 Pod 的工作节点的信息，请参阅识别违规的 Pod 和工作节点。

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

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

有关识别工作负载资源的所有 Pod 及其运行的节点的信息，请参阅使用工作负载名称识别违规的 Pod 和工作节点。

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

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

有关使用服务账号识别所有 Pod 以及它们正在运行的节点的信息，请参阅使用服务账号名称识别违规的 Pod 和工作节点。

确定所有受感染的 Pod 及其运行的节点后，请参阅 Amazon EKS 最佳实践指南，了解如何隔离 Pod、轮换其证书并收集数据以进行取证分析。

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

识别攻击容器组的漏洞。
实施针对该漏洞的修复程序并启动新的替换容器组。
删除易受攻击的容器组。

有关更多信息，请参阅重新部署受感染的 Pod 或工作负载资源。

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

修复可能受损的容器镜像

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

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

立即停止使用该映像，并将其从映像存储库中删除。
使用可能受损的图像识别所有 pod。

有关更多信息，请参阅识别包含可能存在漏洞或受损容器镜像的 pod 和工作节点。
隔离可能受到威胁的 Pod，轮换凭证，并收集数据进行分析。有关更多信息，请参阅 Amazon EKS 最佳实践指南。
使用可能受损的镜像删除所有 pod。

修复可能受到威胁的 Kubernetes 节点

如果 GuardDuty 发现结果中标识的用户代表节点身份，或者发现结果表明使用了特权容器，则发现可能表示节点受损。

如果用户名字段具有以下格式，则用户身份是 Worker 节点：system:node:node name。例如，system:node:ip-192-168-3-201.ec2.internal。这表明对手已获得该节点的访问权限，并且它正在使用该节点的凭据与 Kub API ernetes 端点通信。

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

要修复可能受损的节点，请执行以下操作：

隔离 Pod，轮换其凭证，并收集数据进行取证分析。

有关更多信息，请参阅 Amazon EKS 最佳实践指南。
确定在可能受到威胁的节点上运行的所有 Pod 所使用的服务帐户。查看其权限，并根据需要轮换服务账户。
终止可能受到威胁的节点。

Javascript 在您的浏览器中被禁用或不可用。

要使用 Amazon Web Services 文档，必须启用 Javascript。请参阅浏览器的帮助页面以了解相关说明。

文档惯例

修复可能受损的独立容器

修复运行时监控结果