EKS 安全检查表：安全集群的 10 项最佳实践

Amazon EKS 安全到底是什么？

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

由于 EKS 是 AWS 提供的服务，因此我们可以通过责任共担模型开始讨论安全性。一般来说，AWS 负责管理其云服务的安全性，而客户负责监督工作负载的安全性。

自我管理的工作线程和 EKS 集群配置（例如 IAM、pod、运行时、网络安全、工作线程节点可扩展性和容器映像组件）都由客户负责。

客户端安全包括数据安全、工作节点的升级和补丁，以及一切的安全配置，从数据平面和节点开始，到容器和操作系统结束。客户还需要配置安全组，使 EKS 控制平面能够以安全的方式与虚拟私有云 (VPC) 进行通信。

如果每个 AWS 用户决定使用此托管 Kubernetes 服务来运行其集群，他们将获得以下一些内置 EKS 安全功能。

AWS 秘密管理器

在 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. 不要在特权模式下运行容器

如果您的部署有在特权（根）模式下运行的容器，则它允许容器访问重要的主机资源。这可能会导致安全问题。避免在特权模式下运行容器或打开 podSecurityPolicy 并将特权参数设置为 false。这将确保容器无法运行需要主机上 root 权限的进程。

6. 不要共享主机的IPC或网络命名空间 

查看您的 Pod，看看它们是否共享主机的 IPC 或网络命名空间。为 Pod 和主机进程间通信共享命名空间是危险的，因为它可能会开放对共享信息的访问。因此，决不应该允许 Pod 访问主机命名空间。 

共享 Pod 和主机网络命名空间允许从 Pod 访问主机网络。这打破了网络隔离。在 PodSecurityPolicy 中将 hostNetwork 参数设置为 false，晚上就能睡得更好，因为知道您的集群受到保护。

7.禁用NET_RAW

如果您的 Kubernetes 容器不放弃 NET_RAW 功能，您可能会在集群内启用各种网络漏洞。为了确保 EKS 安全，请使用开放策略代理、Kyverno 或 Kubernetes Pod Security 准入控制器等策略执行解决方案来遵循最佳行业实践。

在 Pod 的 securityContext 定义中设置 ALL 或 NET_RAW 功能的 drop，以确保禁用 NET_RAW 功能。

8.检查不安全/Proc挂载 

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

9. 不要使用根文件系统来保证容器安全

如果您的容器在没有只读根文件系统的情况下运行，请做好遇到麻烦的准备。使用只读文件系统可以防止各种恶意二进制文件写入系统或攻击者接管系统。确保容器仅使用只读文件系统，并在 Pod securityContext 定义中将 readOnlyRootFilesystem 设置为 true。 

10.制定滚动更新策略

最后，为了保持 EKS 的安全性，请制定滚动更新策略。滚动更新可让部署更新通过使用新 Pod 实例增量更新来最大程度地减少应用程序停机时间。

另一点是在运行时进行漏洞扫描，因为存在供应链攻击，所以即使您在 CI/CD 阶段扫描了部署工件，您也需要查看真正影响集群的内容。一般来说，基于代理的安全解决方案比“无代理”的安全解决方案更好，甚至更好。

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

他们在 EKS 安全方面遇到的另一个挑战是安全问题的优先级 - 根据应用程序的大小，确定优先级可能会变得非常耗时。自动化可以加速这一过程，为工程师赢得时间来完成其他任务。