Kubernetes 充满了安全挑战。不可避免地，Amazon Elastic Kubernetes Service (EKS) 等托管 Kubernetes 服务也是如此。加强集群安全性的最佳方法是实施已成为 Kubernetes 社区推荐的行业标准的实践。以下是每个团队保护其集群所需的十大 EKS 安全策略。
Amazon EKS 安全性到底是关于什么的？
Amazon EKS 是目前最受欢迎的托管 Kubernetes 服务之一。它允许团队通过 Kubernetes 编排他们的容器，而无需安装和操作 Kubernetes 控制平面或 Kubernetes 集群运行所需的基础设施。
由于 EKS 是 AWS 提供的一项服务，因此我们可以通过责任共担模型开始讨论安全性。一般来说，AWS 负责管理其云服务的安全性，而客户则负责监督工作负载的安全性。
AWS 通过 EKS 管理 Kubernetes 仪表板和控制平面，包括云提供商用来提供安全 Kubernetes 环境的所有基础设施服务。
IAM、Pod、运行时、网络安全、工作节点可扩展性和容器映像组件等自我管理的工作人员和 EKS 集群配置都属于客户。
客户端安全包括数据安全、工作节点的升级和补丁，以及一切的安全配置，从数据平面和节点开始，到容器和操作系统结束。客户还需要配置安全组，允许 EKS 控制平面以安全的方式与虚拟私有云 (VPC) 通信。
AWS 用户通过以下形式从云提供商处获得有关 EKS 安全性的支持：
- 安全用户指南，
- EKS 最佳实践指南。
AWS 在其托管的 Kubernetes 服务中内置了 EKS 安全功能
如果每个 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 提供商。1
3. 利用 Kubernetes 基于角色的访问控制 (RBAC)
EKS 安全性的另一个与访问相关的最佳实践是使用 RBAC 来定义谁可以访问 Kubernetes API 以及他们拥有什么权限。在 Kubernetes 1.6 及更高版本中，RBAC 通常默认启用。鉴于 Kubernetes 结合了授权控制器，在打开 RBAC 时会禁用传统的基于属性的访问控制 (ABAC)。
选择特定于命名空间的权限而不是集群范围的权限是一个好主意。即使在调试时，也要避免授予集群管理员权限。否则，您的容器安全性可能会受到影响。
4. 避免在环境变量中保密
确保您的对象在环境变量中使用机密，因为系统的其他部分可以轻松访问环境变量。将机密用作文件或从 secretKeyRef 中受益以最大程度地减少潜在威胁。
5. 不要在特权模式下运行容器
如果您的部署有容器以特权 (root) 模式运行，它允许容器访问重要的主机资源。这可能会导致安全问题。避免在特权模式下运行容器或打开 podSecurityPolicy 并将特权参数设置为 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 定义中为 ALL 或 NET_RAW 功能设置 drop 以确保 NET_RAW 功能被禁用。[2, 3]
8. 检查 Unsafe /Proc Mount
使用 unsafe /proc mount (procMount=Unmasked) 的部署允许其他人绕过容器运行时的默认屏蔽行为。如果将容器设置为 Unmasked /procs 挂载类型，则可能会将主机信息暴露给容器，从而导致潜在的数据泄漏或容器逃逸。设置 procMount=Default 以确保容器不暴露 /proc 的任何部分。
9. 不要将根文件系统用于容器安全
如果您的容器在没有只读根文件系统的情况下运行，请做好应对麻烦的准备。使用只读文件系统可以防止各种恶意二进制文件写入系统或被攻击者接管系统。确保容器仅使用只读文件系统，并在 Pod securityContext 定义中将 readOnlyRootFilesystem 设置为 true。
10. 建立滚动更新策略
最后，为了确保您的 EKS 安全，制定滚动更新策略。滚动更新让部署更新通过使用新实例增量更新 pod 实例来最大限度地减少应用程序停机时间。查看Kubernetes 文档中的此页面以获取更多详细信息。
另一点是在运行时进行漏洞扫描，因为存在供应链攻击，因此即使您在 CI/CD 阶段扫描了部署工件，您也需要查看集群真正得到了什么。一般来说，基于代理的安全解决方案比“无代理”解决方案更好甚至更好。
Kubernetes 生态系统在不断发展，其安全性也不例外。随着新威胁的出现和问题的暴露，工程师被迫跟上很多事情——这需要大量的时间和精力。
他们在 EKS 安全方面遇到的另一个挑战是安全问题的优先级 - 根据应用程序的大小，优先级可能会变得非常耗时。自动化可以加快这一进程，为工程师赢得其他任务的时间。
