EKS 安全检查清单：构建安全集群的 10 项最佳实践

Kubernetes 存在诸多安全挑战。不可避免地，托管式 Kubernetes 服务（例如 Amazon Elastic Kubernetes Service (EKS)）也面临着同样的问题。加强集群安全性的最佳方法是实施已成为行业标准并被 Kubernetes 社区推荐的实践。以下是每个团队保护其 EKS 集群所需的 10 项最重要的安全策略。

Amazon EKS 安全究竟包含哪些内容？

Amazon EKS 是目前最受欢迎的托管 Kubernetes 服务之一。它允许团队通过 Kubernetes 编排容器，而无需安装和管理 Kubernetes 控制平面或 Kubernetes 集群运行所需的基础设施。

由于 EKS 是 AWS 提供的一项服务，我们可以从责任共担模型入手来探讨安全性问题。一般来说，AWS 负责管理其云服务的安全性，而客户则负责其工作负载的安全性。

AWS 负责通过 EKS 管理 Kubernetes 控制面板和控制平面，包括云提供商用于提供安全 Kubernetes 环境的所有基础设施服务。 

自管理工作节点和 EKS 集群配置（例如 IAM、Pod、运行时和网络安全、工作节点可扩展性以及容器镜像组件）均由客户负责。客户端安全包括数据安全、工作节点的升级和补丁，以及从数据平面和节点到容器和操作系统的所有安全配置。客户还需要配置安全组，以确保 EKS 控制平面能够以安全的方式与虚拟私有云 (VPC) 通信。

AWS 用户可从云提供商处获得有关 EKS 安全性的支持，具体形式如下：

• 安全用户指南
• EKS最佳实践指南。 

AWS 已将 EKS 安全功能构建到其托管 Kubernetes 服务中。

以下是每个 AWS 用户如果决定使用此托管 Kubernetes 服务运行集群时可以获得的一些内置 EKS 安全功能。

AWS Secrets Manager

在 Kubernetes 中，您可以创建键值对并将其传递给在 Pod 内运行的应用程序。如果键值对包含任何敏感数据，您可以使用 Secret Store，它是 AWS Secrets Manager（以及 AWS Parameter Store）实现的容器存储接口驱动程序。

AWS Secrets Manager 提供了一个集中存储和管理 Kubernetes 密钥的位置。AWS Secrets and Configuration Provider (ASCP) 插件允许用户处理通过 ETCD 接收密钥的传统 Kubernetes 工作负载。您还可以应用 IAM 策略来定义哪些 Pod 有权访问哪些密钥。

身份和访问管理

身份和访问管理 (IAM) 可以帮助每位管理员控制对 AWS 资源的访问。IAM 管理员可以根据特定策略设置哪些用户可以登录以及拥有哪些用户可以访问 EKS 资源。 

用户获取用于 Kubernetes 资源身份验证和授权的凭据。其理念是仅向服务用户授予执行其工作所需的相应功能访问权限。

日志记录和监控

AWS 提供 CloudWatch 服务，用于存储来自控制平面的诊断日志和审计日志。每个 EKS 控制平面都有自己的日志组。监控这些日志至关重要，以便及时发现安全和生产问题。此外，AWS CloudTrail 也提供此功能，它可以记录所有 EKS 活动，并捕获用户、角色、AWS 服务或 EKS 控制台请求发出的 API 调用。

EKS 安全性的 10 个最佳实践

1. 隔离 Kubernetes 节点

避免将 Kubernetes 节点直接暴露给公共网络。理想情况下，这些节点应位于独立的网络中，并且尽可能与公司通用网络没有任何直接连接。 

如何实现这一点？关键在于隔离 Kubernetes 的控制流量和数据流量。否则，它们最终都会流经同一条管道。开放数据平面访问权限意味着开放控制平面访问权限，这对 EKS 安全来说非常不利。使用入口控制器配置节点，并将其设置为仅允许来自主节点的连接通过网络访问控制列表 (ACL) 中指定的端口进入。

2. 加强身份验证和授权

将 Kubernetes 与第三方身份验证提供商集成是一个明智之举。这样，您就可以获得额外的安全功能，例如多因素身份验证。 

为了确保控制平面访问安全，不要在 API 服务器级别管理用户，而应使用 AWS Identity and Access Management (IAM) 解决方案。如果无法使用 CSP IAM，可以选择 OpenID Connect (OIDC) 以及您之前使用过的 SSO 提供商^。 

3. 利用 Kubernetes 基于角色的访问控制 (RBAC)

另一个与访问控制相关的 EKS 安全最佳实践是使用基于角色的访问控制 (RBAC) 来定义哪些用户可以访问 Kubernetes API 以及他们拥有哪些权限。在 Kubernetes 1.6 及更高版本中，RBAC 通常默认启用。鉴于 Kubernetes 集成了多个授权控制器，启用 RBAC 时，请禁用传统的基于属性的访问控制 (ABAC)。

建议使用命名空间特定的权限，而不是集群范围的权限。即使在调试过程中，也应避免授予集群管理员权限。否则，容器安全可能会受到威胁。

4. 避免在环境变量中保存秘密信息

请确保您的对象使用环境变量中的密钥，因为系统的其他部分可以轻松访问环境变量。将密钥作为文件存储，或利用 secretKeyRef 来最大程度地降低潜在威胁。

5. 不要以特权模式运行容器

如果您的部署中包含以特权（root）模式运行的容器，则容器可以访问重要的主机资源，这可能会导致安全问题。请避免以特权模式运行容器，或者启用 podSecurityPolicy 并将 privileged 参数设置为 false。这将确保容器无法运行需要在主机上拥有 root 权限的进程。

6. 不要共享主机的进程间通信 (IPC) 或网络命名空间 

检查一下你的 Pod，看看它们是否共享了宿主机的进程间通信 (IPC) 或网络命名空间。共享 Pod 和宿主机进程间通信的命名空间是危险的，因为它可能导致共享信息的泄露。因此，绝对不应该允许 Pod 访问宿主机的命名空间。 

共享 Pod 和主机网络命名空间允许 Pod 访问主机网络，这会破坏网络隔离。请在 PodSecurityPolicy 中将 hostNetwork 参数设置为 false，这样您就可以安心入睡，因为您的集群已受到保护。

7. 禁用 NET_RAW

如果您的 Kubernetes 容器没有禁用 NET_RAW 功能，则可能会在集群内部启用各种网络攻击。为了确保 EKS 的安全性，请使用策略执行解决方案，例如 Open Policy Agents、Kyverno 或 Kubernetes Pod Security 准入控制器，以遵循最佳行业实践。在 Pod 的 securityContext 定义中，将 NET_RAW 功能设置为禁用（例如，全部禁用或禁用 NET_RAW 功能），以确保禁用 NET_RAW 功能。[2, 3]

8. 检查 /proc 挂载是否安全 

使用不安全的 /proc 挂载方式（procMount=Unmasked）部署允许其他程序绕过容器运行时的默认屏蔽行为。如果将容器的 /proc 挂载类型设置为 Unmasked，则可能会将主机信息暴露给容器，从而导致潜在的数据泄露或容器逃逸。请将 procMount 设置为 Default，以确保容器不会暴露 /proc 的任何部分。

9. 不要将根文件系统用于容器安全

如果您的容器运行在非只读根文件系统的情况下，请做好应对问题的准备。使用只读文件系统可以防止各种恶意二进制文件写入系统或防止攻击者控制系统。请确保容器仅使用只读文件系统，并在 Pod 安全上下文定义中将 `readOnlyRootFilesystem` 设置为 `true`。 

10. 构建滚动更新策略

最后，为了确保 EKS 的安全性，请制定滚动更新策略。滚动更新允许部署更新通过逐步更新 Pod 实例来最大限度地减少应用程序停机时间。有关更多详细信息，请参阅Kubernetes 文档中的此页面。

另一点是需要在运行时进行漏洞扫描，因为存在供应链攻击，所以即使您在 CI/CD 阶段已经扫描了部署工件，也需要了解集群中究竟有哪些漏洞被入侵。一般来说，基于代理的安全解决方案比“无代理”解决方案更好，甚至更胜一筹。

借助专家帮助实现 EKS 安全

Kubernetes 生态系统正在不断发展，其安全性也不例外。随着新威胁的出现和问题的暴露，工程师们不得不跟进很多方面——这需要花费大量的时间和精力。

他们在 EK 安全方面遇到的另一个挑战是安全问题的优先级排序——根据应用程序的规模，优先级排序可能非常耗时。自动化可以加快这一过程，从而为工程师节省时间，让他们能够处理其他任务。

CAST AI 的云安全功能会根据行业最佳实践、Kubernetes 建议和容器安全系统基准检查集群，然后自动确定优先级，让您从一开始就走上正确的道路。

对照配置和安全最佳实践扫描您的 Kubernetes 集群，找出最佳的安全防护方法。

检查您的 Kubernetes 集群是否符合要求配置和安全最佳实践

连接您的集群，5分钟内即可查看您的成本，无需信用卡。

开始使用

参考

• ^[1] -https://kubernetes.io/docs/reference/access-authn-authz/authentication/#authentication-strategies
• ^[2] - https://kubernetes.io/docs/concepts/security/pod-security-admission/
• ^[3] - https://kubernetes.io/docs/concepts/security/pod-security-standards/