官方公众号企业安全新浪微博

FreeBuf+小程序把安全装进口袋

• 容器安全

关于AWS Fargate

AWS Fargate 是可以与 Amazon ECS结合使用的技术，让您在运行容器时不需要管理服务器或集群。使用 AWS Fargate，你不需要搭建控制平面，只需选择合适的实例类型，或配置应用程序堆栈的所有其它部分，比如网络、扩展、服务发现、负载均衡，安全组、权限或密钥管理。你只需要构建容器镜像，定义希望它如何运行、在何处运行，并为实际需要的资源付费。Fargate天生与Amazon VPC、自动扩展（Auto Scaling）、弹性负载均衡（ELB）、身份及访问管理（IAM）角色和密钥管理集成起来。AWS花了很多时间让Fargete随时可用于生产环境，制定了确保正常运行时间达到99.99%的服务级别协议（SLA），符合支付卡行业数据安全标准（PCI）、服务组织控制（SOC）、ISO和《健康保险可携性及责任性法案》（HIPAA）等法规或标准。

目前，Amazon ECS 具有两种模式：Fargate 启动类型和 EC2 启动类型。如果使用 Fargate 启动类型，您只需将应用程序打包到容器中，指定 CPU 和内存需求，选择awsvpc网络模型和 IAM 策略，然后直接启动应用程序。如果使用EC2 启动类型，您可以对运行容器应用程序的基础设施进行更精细的服务器级控制。Amazon ECS负责跟踪集群中的所有 CPU、内存及其他资源，并根据您指定的资源要求查找最适合运行容器的服务器。无论你使用Kubernetes、Mesos、Rancher、Nomad、ECS还是其他任何系统，有了Fargate，唯一要管理的是仅仅是应用程序本身的逻辑。AWS Fargate终于让容器在云计算的环境里发挥地淋漓尽致。

AWS Fargate安全概述

像AWS Fargate这样的无服务器计算模型由于其可扩展性、生产效率和成本效益等各种优势，现在正被广泛使用。在普通的虚拟机中，用户必须同时管理应用程序和基础设施。除此之外，用户还需要配置和管理计算资源，并为所有VM实例付费，而不是用户应用程序实际消耗的资源量。有了无服务器平台，用户只需构建和管理他们的应用程序，就不必担心管理、扩展或修复他们的基础设施，用户也只为运行应用程序所需的实际资源付费。

下图显示的是Fargate中虚拟机与普通虚拟机之间的对比：

AWS Fargate是当今最流行的无服务器平台之一，目前已在近三分之一的AWS容器环境中广泛使用。AWS Fargate允许用户直接运行容器，而无需管理其底层EC2主机或担心扩展问题。然而，保护AWS Fargate容器是一个很大的挑战，因为它们通常具有更大的攻击面，并且很难监视和控制用户的工作负载。目前来说，包括云安全解决方案在内的传统安全解决方案在保护无服务器部署方面的效率是非常低的，而且有效性还值得考量。

AWS Fargate面临的安全挑战

下面我们将跟大家讨论一些关于AWS Fargate面临的安全问题，这些问题使得监控和保护AWS Fargate容器成为了一个巨大的挑战。

• 第一个挑战-无主机访问：在AWS Fargate的部署过程中，AWS会负责运营和管理虚拟机。此时，用户是无权访问底层主机的。Fargate容器无法加载主机文件系统。虽然这简化了管理并提高了生产效率，但也使监视和保护部署变得更加困难。
• 第二个挑战-指令注入的困难：在AWS Fargate实例中运行的应用程序没有root权限，这使得对用户应用程序进行有效的运行时插装以监视进程活动成为一项非常具有挑战性的任务。目前有两种比较有效的指令注入方法，比如说通过Kernel模块和eBPF。但是，如果没有root权限，上述这两种方法在AWS Fargate上都是不可行的。最近，AWS Fargate增加了对ptrace的支持。我们可以使用ptrace进行指令注入，它是准确的，因为它直接拦截内核系统调用，不容易被绕过。但是，它的效率不是很高，因为它需要高开销的操作系统上下文切换，而且可能无法跨不同的体系结构进行移植。在没有特权访问的情况下，可以使用LD_PRELOAD环境变量来检测代码，以截获libc等库调用的系统调用，并记录调用及其参数。但是，由于应用程序可以直接调用内核函数，因此它不是非常精确。通过直接调用系统调用而不是使用库，攻击者也更容易智取并绕过这种类型的监视。
• 第三个挑战-文件系统监控：在基于Linux的系统中，fanotify和inotify是两种广泛使用的高效文件系统监控方法。但是，fanotify系统调用需要CAP_SYS_ADMIN功能，这在AWS Fargate实例中是无法使用的。因此，有效监视文件系统活动的唯一可行方法是使用inotify系统调用。不幸的是，基于inotify的方法有一些缺点，限制了我们可以收集和阻止攻击的信息量。我们无法获得执行文件活动的进程的PID，并且没有使用inotify进行访问权限决策的机制。
• 第四个挑战-网络监控：由于缺乏对ebpf等高效内核级跟踪机制的支持，AWS Fargate环境中对网络连接和网络数据包的有效监控也具有挑战性。这也使得安全解决方案退回到效率较低的方法来监视网络连接和数据包。
• 第五个挑战-部署模型：缺乏特权访问这个事实也破坏了在AWS Fargate上部署代理来监视容器的标准sidecar模型。由于无法访问主机，sidecar代理容器无法监视AWS Fargate主机上运行的其他容器。当然了，现在也有一些在AWS Fargate实例上部署代理的替代方法。首先，当容器开始执行其入口点代码时，我们可以自动下载并在应用程序容器中安装代理。然而，这种方法违反了容器不变性的原则。其次，我们可以修改dockerfile以通过CI/CD添加代理。第三，我们可以将代理保留为一个sidecar容器，该容器可以作为卷装载，以便其他正在运行的容器可以访问代理并在容器实例化之后运行代理。然而，这三种方法都有其他问题和挑战。一个主要问题是AWS Fargate上的每个应用程序容器都将运行自己的代理，而一个代理会监视一个EC2实例上运行的所有容器，因此增加了监视的开销。
• 第六个挑战-终止攻击很困难：AWS的安全解决方案使用诸如iptables或nftables之类的实用程序来阻止攻击者通信并保护虚拟机和容器的安全。但是，我们却无法在AWS Fargate实例上运行iptables或nftables并阻止攻击者的活动，因为这些工具还需要root权限。
• 第七个挑战-Kubernetes支持：由于缺乏对节点的访问以及对AWS Fargate容器内Kubernetes API的有限访问，使得在AWS Fargate上保护Kubernetes成为一项困难的任务，因为一些安全功能依赖于这些API。

总结

综上所述，在监控和保护AWS Fargate容器方面目前还存在着许多技术挑战和问题。由于缺乏对主机的访问以及对ebpf和fanotify等技术的支持，因此需要使用其他替代技术和仔细的优化来构建一个高效的监控系统，以确保AWS Fargate部署的安全。