运行时系统安全性 - Amazon EKS

本文属于机器翻译版本。若本译文内容与英语原文存在差异,则一律以英文原文为准。

运行时系统安全性

运行时安全性为您的容器在运行时提供主动保护。其目的是检测, and/or 防止容器内发生恶意活动。这可以通过 Linux 内核中的许多机制或与 Kubernetes 集成的内核扩展来实现,例如 Linux 功能、安全计算 (seccomp) 或。 AppArmor SELinux还有诸如Amazon GuardDuty 和第三方工具之类的选项,可以减少对Linux内核机制的手动配置,从而帮助建立基准和检测异常活动。

重要

Kubernetes 目前没有提供任何用于将 seccomp 或配置文件加载到节点上的原生机制。 AppArmor SELinux 它们要么必须手动加载,要么在启动时安装到节点上。这必须在你的 Pod 中引用它们之前完成,因为调度器不知道哪些节点有配置文件。参见下文,诸如安全配置文件操作员之类的工具如何帮助将配置文件自动配置到节点。

安全上下文和内置 Kubernetes 控件

许多 Linux 运行时安全机制都与 Kubernetes 紧密集成,可以通过 Kubernetes 安全上下文进行配置。其中一个选项是privileged标志,false默认情况下,该标志处于启用状态,则基本上等同于主机上的 root。在生产工作负载中启用特权模式几乎总是不合适的,但是还有更多的控件可以根据需要为容器提供更精细的权限。

Linux 功能

Linux 功能允许您向 Pod 或容器授予某些功能,而无需提供 root 用户的所有能力。示例包括CAP_NET_ADMIN,它允许配置网络接口或防火墙CAP_SYS_TIME,或者允许操纵系统时钟。

Seccomp

使用安全计算 (seccomp),您可以防止容器化应用程序对底层主机操作系统的内核进行某些系统调用。虽然 Linux 操作系统有几百个系统调用,但其中大部分并不是运行容器所必需的。通过限制容器可以进行的系统调用,可以有效地减少应用程序的攻击面。

Seccomp 的工作原理是拦截系统调用,并且只允许那些被列入许可名单的系统调用通过。Docker 有一个默认的 seccomp 配置文件,适用于大多数通用工作负载,而其他容器运行时(例如 containerd)则提供了类似的默认值。你可以在 Pod 规范的securityContext部分中添加以下内容,将你的容器或 Pod 配置为使用容器运行时的默认 seccomp 配置文件:

securityContext: seccompProfile: type: RuntimeDefault

从 1.22 开始(在 alpha 版本中,从 1.27 起稳定),上面的内容RuntimeDefault可以使用单个 kubel et 标志用于节点上的所有 Pod。--seccomp-default然后,只有其他配置文件securityContext才需要中指定的配置文件。

也可以为需要额外权限的内容创建自己的配置文件。手动执行此操作可能非常繁琐,但是有一些工具,例如 Inspektor Gadget(在网络安全部分也推荐用于生成网络策略)和安全配置文件操作员,它们支持使用诸如eBPF或日志之类的工具将基准权限要求记录为seccomp配置文件。Security Profiles Operator 还允许自动将录制的配置文件部署到节点,以供 Pod 和容器使用。

AppArmor 和 SELinux

AppArmor 并 SELinux 被称为强制访问控制或 MAC 系统。它们在概念上与 seccomp 相似,但具有不同的功能 APIs ,允许对特定的文件系统路径或网络端口等进行访问控制。对这些工具的支持取决于 Linux 发行版,以及对 Linux 2023 的 Debian/Ubuntu 支持 AppArmor 和 RHEL/CentOS/Bottlerocket/Amazon Linux 2023 的支持 SELinux。有关进一步的讨论,另请参阅基础架构安全部分 SELinux。

AppArmor 和 SELinux 都与 Kubernetes 集成,但是从 Kubernetes 1.28 开始, AppArmor 配置文件必须通过注释指定,而 SELinux 标签可以直接通过安全上下文的 “SELinux选项” 字段进行设置。

与 seccomp 配置文件一样,上面提到的安全配置文件操作员可以帮助将配置文件部署到集群中的节点上。(将来,该项目还旨在为seccomp生成配置文件, AppArmor SELinux 以及为seccomp生成配置文件。)

建议

使用 Amazon GuardDuty 进行运行时监控和检测对您的 EKS 环境的威胁

如果您目前没有用于持续监控 EKS 运行时和分析 EKS 审核日志以及扫描恶意软件和其他可疑活动的解决方案,Amazon 强烈建议那些想要简单、快速、安全、可扩展且经济实惠的一键式方法来保护 AWS 环境的客户使用 A ma GuardDuty zon。Amazon GuardDuty 是一项安全监控服务,用于分析和处理基础数据源,例如 AWS CloudTrail 管理事件、AWS CloudTrail 事件日志、VPC 流日志(来自亚马逊 EC2 实例)、Kubernetes 审计日志和 DNS 日志。它还包括 EKS 运行时监控。它使用不断更新的威胁情报源(例如恶意 IP 地址和域名列表)以及机器学习来识别您的 AWS 环境中意外、可能未经授权的恶意活动。这可能包括权限升级、使用暴露的凭证、与恶意 IP 地址、域名通信、Amazon EC2 实例和 EKS 容器工作负载上存在恶意软件或发现可疑 API 活动等问题。 GuardDuty 通过生成可在 GuardDuty 控制台或通过 Amazon EventBridge 查看的安全调查结果来通知您 AWS 环境的状态。 GuardDuty 还支持您将调查结果导出到亚马逊简单存储服务 (S3) 存储桶,并与 AWS Security Hub 和 Detective 等其他服务集成。

观看这场 AWS 在线技术讲座 “使用亚马逊增强对亚马逊 EKS 的威胁检测 GuardDuty ——AWS 在线技术讲座”,了解如何在几分钟内启用这些额外的 EKS 安全功能 step-by-step。

可选:使用第三方解决方案进行运行时监控

如果你不熟悉 Linux 的安全性,那么创建和管理 seccomp 和 Apparmor 配置文件可能会很困难。如果您没有时间精通,可以考虑使用第三方商业解决方案。他们中的许多人已经超越了Apparmor和seccomp等静态配置文件,并开始使用机器学习来阻止或提醒可疑活动。其中一些解决方案可以在下面的工具部分中找到。其他选项可以在适用于容器的 AWS Marketplace 上找到。

在编写 seccomp 策略之前,请考虑 add/dropping Linux 功能

功能包括对可通过 syscalls 访问的内核函数进行各种检查。如果检查失败,系统调用通常会返回错误。检查可以在特定 syscall 的开头完成,也可以在内核的深处,在可能通过多个不同的系统调用(例如写入特定的特权文件)访问的区域中完成。另一方面,Seccomp 是一个系统调用过滤器,在所有系统调用运行之前将其应用于所有系统调用。进程可以设置过滤器,允许他们撤消运行某些系统调用的权限,或者撤消某些系统调用的特定参数的权利。

在使用 seccomp 之前,请考虑 adding/removing Linux 功能是否为你提供了所需的控制权。有关更多信息,请参阅为容器设置功能

看看你能否通过使用 Pod 安全策略来实现自己的目标 (PSPs)

Pod 安全策略提供了许多不同的方法来改善您的安全状况,而不会引入过多的复杂性。在冒险构建 seccomp 和 Apparmor 配置文件 PSPs 之前,请先探索中可用的选项。

警告

从 Kubernetes 1.25 起, PSPs 已被移除并替换为 Pod 安全准入控制器。现有的第三方替代方案包括 OPA/Gatekeeper 和Kyverno。 PSPs 可以从 Gatekeeeper 库存储库中提取一组常见的用于实现策略的 Gatekeeper 约束和约束模板。 GitHub在 Kyverno策略库中 PSPs 可以找到许多替代方案,包括 Pod 安全标准的完整集合。

工具和资源