本文属于机器翻译版本。若本译文内容与英语原文存在差异,则一律以英文原文为准。
修复发现的 Kubernetes 安全问题 GuardDuty
亚马逊 GuardDuty 生成的调查结果表明,在为您的账户启用 EK GuardDuty S 保护后,可能会出现 Kubernetes 安全问题。有关更多信息,请参阅亚马逊的 EKS 保护 GuardDuty:以下各节介绍这些场景的建议补救步骤。该特定发现类型的条目中描述了特定的补救措施。您可以通过从 “有效的查找结果类型” 表格中选择查找结果类型来访问有关该查找结果的完整信息。
不同类型的攻击和配置问题可能会触发 GuardDuty Kubernetes 的调查结果。本指南可帮助您确定针对集群的 GuardDuty 发现的根本原因,并概述了相应的补救指南。以下是导致 GuardDuty Kubernetes 发现的主要根本原因:
在 Kubernetes 版本 1.14 之前,system:basic-user
ClusterRoles默认情况下,该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 管理员的访问权限,请执行以下操作:
-
userType
从该Access Key details
部分中找出。-
如果
userType
是角色并且该角色属于 EC2 实例角色:-
识别该实例,然后按照中的说明进行操作修复受损的 EC2 实例。
-
-
如果
userType
是用户,或者是用户担任的角色:-
轮换用户有权访问的所有密钥。
-
查看 “我的Amazon账户可能被盗用
” 中的信息,了解更多详情。
-
-
- OIDC 认证用户-通过 OIDC 提供商授予访问权限的用户。通常,OIDC 用户使用电子邮件地址作为用户名。您可以使用以下命令来检查集群是否使用 OIDC:
aws eks list-identity-provider-configs --cluster-name
your-cluster-name
-
要撤消已通过 OIDC 身份验证的用户的访问权限,请执行以下操作:
-
在 OIDC 提供商中轮换该用户的证书。
-
轮换用户有权访问的所有密钥。
-
- Amazon-Auth ConfigMap 定义的用户 — 通过Amazon-auth 获得访问权限的 IAM 用户 ConfigMap。有关更多信息,请参阅 &EKS; 用户指南中的管理集群的用户或 IAM 角色。您可以使用以下命令来查看他们的权限:
kubectl edit configmaps aws-auth --namespace kube-system
-
要撤消Amazon ConfigMap用户的访问权限,请执行以下操作:
-
使用以下命令打开 ConfigMap。
kubectl edit configmaps aws-auth --namespace kube-system
-
识别 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 -
将该用户从 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 服务帐号。
- 服务帐号 — 服务帐号为 pod 提供身份,可通过以下格式的用户名进行识别:
system:serviceaccount:
.namespace
:service_account_name
-
要撤消对服务帐号的访问权限,请执行以下操作:
-
轮换服务帐号凭证。
-
查看下一节中的 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:
. 使用 “使用服务账户名识别违规 Pod 和工作节点namespace
:service_account_name
” 中的说明,使用服务帐号识别所有 Pod 及其正在运行的节点。
确定所有受感染的 Pod 及其运行的节点后,使用 EKS 最佳实践指南中的以下
要修复受损的 pod,请执行以下操作:
-
找出危害 pod 的漏洞。
-
修复该漏洞并启动新的替换 pod。
-
删除有漏洞 Pod。有关更多信息,请参阅重新部署受损的 Pod 或工作负载资源
。
如果已为工作节点分配了一个允许 Pod 访问其他Amazon资源的 IAM 角色,请从实例中移除这些角色以防止攻击造成进一步损害。同样,如果已为 Pod 分配了 IAM 角色,请评估您是否可以在不影响其他工作负载的情况下安全地从该角色中删除 IAM 策略。
修复泄露的容器映像
当 GuardDuty 发现表明 pod 遭到入侵时,用于启动 pod 的图像可能是恶意的或受损的。 GuardDuty 发现可识别resource.kubernetesDetails.kubernetesWorkloadDetails.containers.image
现场内的容器映像。您可以通过扫描图像中是否存在恶意软件来确定该图像是否为恶意图像。
要修复受损的容器镜像,请执行以下操作:
-
立即停止使用该图像并将其从您的图像存储库中删除。
-
使用图像识别所有豆荚。有关更多信息,请参阅识别具有易受攻击或受损容器映像的容器镜像和工作节点的 pod
。 -
隔离受感染的 pod,轮换凭证并收集数据进行分析。有关更多信息,请参阅 EKS 最佳实践指南中的
以下说明。 -
使用受损映像删除所有 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
要修复受感染的节点,请执行以下操作:
-
使用 EKS 最佳实践指南中的
说明隔离 Pod、轮换其凭证并收集用于取证分析的数据。 -
识别节点上运行的所有 Pod 使用的服务帐号。查看他们的权限,并在需要时轮换服务帐号。
-
终止节点。