使用 Amazon EKS 上的 F5 NGINX App Protect 实现安全性左移

根据F5《 2022年application战略状况》报告，企业数字化转型在全球范围内持续加速。 大多数企业在多个云区域部署 200 到 1,000 个应用程序，当今的应用程序正在从单一架构转变为现代分布式架构。

仅仅六年前，Kubernetes 于 2016 年首次进入科技领域并得到主流应用。 如今，全球有超过 75% 的组织在生产中运行容器化应用，这一数字比 2019 年增长了 30%。 Kubernetes 环境（包括 Amazon Elastic Kubernetes Service (EKS)）中的一个关键问题是安全性。 安全性常常是在应用程序开发过程结束时才“附加”的，有时甚至要等到容器化应用启动并运行之后才附加。

当前，数字化转型浪潮因新冠疫情而加速，迫使许多企业采取更全面的安全方法，并考虑“左转”战略。 安全左移意味着在软件开发生命周期 (SDLC) 早期引入安全措施，并在应用、容器、微服务和 API 的 CI/CD 管道的每个阶段使用安全工具和控制。 它代表着向一种名为 DevSecOps 的新范式的转变，其中安全性被添加到 DevOps 流程中并集成到现代软件应用程序开发和交付典型的快速发布周期中。

DevSecOps 代表着重大的文化转变。 安全和 DevOps 团队有一个共同的目标：快速、安全地将高质量的产品推向市场。 开发人员不再会因为安全程序阻碍他们的工作流程而感到受阻。 安全团队不再需要重复修复相同的问题。 这使得组织能够保持强大的安全态势，在漏洞、错误配置以及违反合规性或政策的行为发生时及时发现和预防。

将安全性左移并将安全性自动化为代码可以从一开始就保护您的 Amazon EKS 环境。 学习如何做好大规模生产准备是构建 Kubernetes 基础的重要部分。 对 Amazon EKS 进行适当的治理有助于提高整个企业的效率、透明度和责任感，同时控制成本。 强大的治理和安全护栏创建了一个框架，以更好地了解和控制您的集群。 如果没有它们，您的组织将面临更大的安全漏洞风险以及与收入和声誉损害相关的长尾成本。

要了解有关转向安全第一策略时需要考虑的事项的更多信息，请查看 O'Reilly 的最新报告《application安全的左移》 。

使用 GitOps 实现 Amazon EKS 的自动化安全

自动化是 DevSecOps 的重要推动因素，即使在快速的开发和部署过程中也能帮助保持一致性。 与基础设施即代码一样，使用安全即代码方法实现自动化需要使用声明性策略来维护所需的安全状态。

GitOps 是一个促进自动化的操作框架，以支持和简化应用交付和集群管理。 GitOps 的主要思想是拥有一个 Git 存储库，用于存储 Kubernetes 对象的声明性策略和在 Kubernetes 上运行的应用（定义为代码）。 自动化流程完善了 GitOps 范式，使得生产环境与所有存储的状态描述相匹配。

该存储库以安全策略的形式充当真相来源，然后作为 CI/CD 管道流程的一部分，由声明性配置即代码描述引用。 例如，NGINX 维护一个GitHub 存储库，其中包含 F5 NGINX App Protect 的 Ansible 角色，我们希望这有助于希望将安全性左移的团队。

有了这样的 repo，部署新的应用或更新现有的应用程序只需更新 repo 即可。 自动化流程管理其他一切事务，包括应用配置和确保更新成功。 这可确保所有操作都发生在开发人员的版本控制系统中，并进行同步，以加强业务关键型应用的安全性。

在 Amazon EKS 上运行时，GitOps 可以使安全性变得无缝且强大，同时几乎消除了人为错误并跟踪随时间推移应用的所有版本更改。

NGINX App Protect 和 NGINX Ingress Controller 保护 Amazon EKS 中的应用程序和 API

Kubernetes 安全策略的强大设计必须满足 SecOps 和 DevOps 的需求，并包含随着环境扩展而适应的规定。 Kubernetes 集群可以通过多种方式共享。 例如，一个集群可能有多个应用在其中运行并共享其资源，而在另一种情况下，一个应用有多个实例，每个实例用于不同的最终用户或组。 这意味着安全边界并不总是明确的，需要灵活、细粒度的安全策略。

整体安全设计必须足够灵活以适应异常情况，必须轻松集成到 CI/CD 管道中，并且必须支持多租户。 在 Kubernetes 上下文中，租户是与特定业务部门、团队、用例或环境相关的 Kubernetes 对象和应用的逻辑分组。 那么，多租户意味着多个租户安全地共享同一个集群，租户之间的边界根据与业务需求紧密相关的技术安全要求来强制执行。

在 Amazon EKS 上实现低延迟、高性能安全性的简单方法是将NGINX App Protect WAF 和 DoS模块与NGINX Ingress Controller嵌入。 我们的其他竞争对手均不提供此类在线解决方案。 使用具有同步技术的产品可以带来多种优势，包括减少计算时间、成本和工具蔓延。 以下是一些额外的好处。

• 保护应用边界——在架构良好的 Kubernetes 部署中，NGINX Ingress Controller 是数据平面流量流向 Kubernetes 内运行的服务的唯一入口点，使其成为 WAF 和 DoS 保护的理想位置。
• 整合数据平面——将 WAF 嵌入 NGINX Ingress Controller 中，无需单独的 WAF 设备。 这降低了复杂性、成本和故障点的数量。
• 整合控制平面——可以使用 Kubernetes API 管理 WAF 和 DoS 配置，从而大大简化 CI/CD 流程的自动化。 NGINX Ingress Controller 配置符合 Kubernetes 基于角色的访问控制 (RBAC) 实践，因此您可以安全地将 WAF 和 DoS 配置委托给专门的 DevSecOps 团队。

NGINX App Protect WAF 和 DoS 的配置对象在 NGINX Ingress Controller 和NGINX Plus之间是一致的。 主配置可以轻松转换并部署到任一设备，从而更容易以代码形式管理 WAF 配置并将其部署到任何应用环境。

要将 NGINX App Protect WAF 和 DoS 构建到 NGINX Ingress Controller 中，您必须同时订阅 NGINX Plus 和 NGINX App Protect WAF 或 DoS。 只需几个简单的步骤即可构建集成的NGINX Ingress Controller 映像（Docker 容器）。 部署镜像后（例如手动或使用Helm 图表），您可以使用熟悉的 Kubernetes API 管理安全策略和配置。

基于 NGINX Plus 的 NGINX Ingress Controller 提供对身份验证、基于 RBAC 的授权以及与 pod 的外部交互的精细控制和管理。 当客户端使用 HTTPS 时，NGINX Ingress Controller 可以终止 TLS 并解密流量以应用第 7 层路由并实施安全性。

然后可以部署 NGINX App Protect WAF 和 NGINX App Protect DoS 来实施安全策略，以防止第 7 层的点攻击，作为轻量级软件安全解决方案。 NGINX App Protect WAF 可保护 Kubernetes 应用程序免受 OWASP Top 10 攻击，并提供高级签名和威胁防护、机器人防御和 Dataguard 保护以防止个人身份信息 (PII) 被利用。 NGINX App Protect DoS 在第 4 层和第 7 层提供了额外的防线，通过用户行为分析和应用程序健康检查来缓解复杂的应用层 DoS 攻击，以防止包括 Slow POST 、Slowloris、洪水攻击和 Challenger Collapsar 在内的攻击。

这些安全措施可以保护 REST API 和使用 Web 浏览器访问的应用。 API 安全性也在南北流量流之后的入口级别得到强制执行。

带有 NGINX App Protect WAF 和 DoS 的 NGINX Ingress Controller 可以根据每个请求而不是每个服务保护 Amazon EKS 流量：这是第 7 层流量的更有用的视图，也是实施 SLA 和南北 WAF 安全的更好方法。

GigaOm 的最新高性能 Webapplication防火墙测试报告显示了 NGINX App Protect WAF 如何持续提供强大的应用程序和 API 安全性，同时保持高性能和低延迟，并且在所有测试的攻击率下均优于其他三种测试的 WAF – AWS WAF、Azure WAF 和 Cloudflare WAF。

举例来说，图 4 显示了测试结果，其中 WAF 必须处理每秒 500 个请求（RPS），其中 95%（475 RPS）的请求有效，5% 的请求（25 RPS）是“坏的”（模拟脚本注入）。 在第 99 个百分位，NGINX App Protect WAF 的延迟比 AWS WAF 低 10 倍，比 Cloudflare WAF 低 60 倍，比 Azure WAF 低 120 倍。

图 5 显示了每个 WAF 在 100% 成功率（无5xx或429我们的目标是减少 100% 的错误，并且每个请求的延迟时间不超过 30 毫秒。 NGINX App Protect WAF 处理速度为 19,000 RPS，而 Cloudflare WAF 处理速度为 14,000 RPS，AWS WAF 处理速度为 6,000 RPS，Azure WAF 仅处理速度为 2,000 RPS。

如何在 Amazon EKS 上部署 NGINX App Protect 和 NGINX Ingress Controller

NGINX App Protect WAF 和 DoS 利用以应用程序为中心的安全方法，具有完全声明式配置和安全策略，可轻松将安全性集成到 Amazon EKS 上应用生命周期的CI/CD 管道中。

NGINX Ingress Controller 提供了多个自定义资源定义(CRD) 来管理 Web应用安全的各个方面，并支持共享责任和多租户模型。 CRD 清单可以按照组织使用的命名空间分组应用，以支持多个操作组的所有权。

在 Amazon EKS 上发布应用时，您可以利用已在使用的自动化管道并在其上分层 WAF 安全策略来构建安全性。

此外，使用 NGINX Ingress Controller 上的 NGINX App Protect，您可以配置 CPU 和内存利用率的资源使用阈值，以防止 NGINX App Protect 导致其他进程挨饿。 这在 Kubernetes 等依赖资源共享且可能受到“吵闹邻居”问题影响的多租户环境中尤为重要。

使用 NGINX CRD 配置日志记录

NGINX App Protect 和 NGINX Ingress Controller 的日志在设计上是分开的，以反映安全团队通常如何独立于 DevOps 和应用所有者运行。 您可以将 NGINX App Protect 日志发送到可从 Kubernetes pod 访问的任何 syslog 目标，方法是将app-protect-security-log-destination注释的参数设置为 syslog pod 的集群 IP 地址。 此外，您可以使用APLogConf资源来指定您关心的 NGINX App Protect 日志，以及将哪些日志推送到 syslog pod。 NGINX Ingress Controller 日志被转发到本地标准输出，就像所有 Kubernetes 容器一样。

此示例 APLogConf 资源指定记录所有请求（不仅仅是恶意请求）并设置可以记录的最大消息和请求大小。

api版本：appprotect.f5.com/v1beta1 种类： APLogConf 
元数据： 
名称：logconf 
命名空间：dvwa 
规格： 
内容： 
格式：默认 
max_message_size： 64k 
max_request_size: 任意 
过滤器: 
request_type: 全部

使用 NGINX CRD 定义 WAF 策略

APPolicy Policy 对象是一个 CRD，它基于声明式方法定义具有签名集和安全规则的 WAF 安全策略。 这种方法适用于 NGINX App Protect WAF 和 DoS，而以下示例重点介绍 WAF。 策略定义通常作为 SecOps 目录的一部分存储在组织的真相源中。

api版本：appprotect.f5.com/v1beta1 种类： APPolicy 
元数据： 
名称：sample-policy
规范： 
策略： 
名称：sample-policy 
模板： 
名称： POLICY_TEMPLATE_NGINX_BASE 
applicationLanguage: utf-8 
reinforcementMode: 阻止 
signature-sets: 
- 名称： 命令执行签名 
alarm: true 
block: true
[...]

将安全策略清单应用于 Amazon EKS 集群后，创建一个名为log-violations的 APLogConf 对象，以定义当请求违反 WAF 策略时写入日志的条目类型和格式：

api版本：appprotect.f5.com/v1beta1 种类： APLogConf 
元数据： 
名称：log-violations
规格： 
内容： 
格式：默认 
max_message_size： 64k 
max_request_size: 任意 
过滤器: 
request_type: 非法

然后，当应用由 NGINX Ingress Controller 公开时， waf-policy Policy 对象引用 NGINX App Protect WAF 的sample-policy来对传入流量进行强制执行。 它引用日志违规来定义发送到logDest字段中指定的 syslog 服务器的日志条目的格式。

api版本：k8s.nginx.org/v1 种类： 策略 
元数据： 
名称：waf-policy 
规范： 
waf： 
启用：true 
apPolicy：“default/sample-policy” 
securityLog： 
启用：true 
apLogConf：“default/log-violations” 
logDest：“syslog：server = 10.105.238.128：5144”

当 DevOps 发布一个VirtualServer对象，该对象配置 NGINX Ingress Controller 以在 Amazon EKS 上公开应用时，部署完成：

api版本：k8s.nginx.org/v1kind： 虚拟服务器
元数据：
名称：eshop-vs
规格：
主机：eshop.lab.local
策略：
-名称：default/waf-policy
上游：
-名称：eshop-upstream
服务：eshop-service
端口： 80
路线：
- 路径：/
操作：
密码：eshop-upstream

VirtualServer 对象可以轻松发布和保护在 Amazon EKS 上运行的容器化应用程序，同时坚持共享责任模型，其中 SecOps 提供了全面的安全策略目录，而 DevOps 依靠它从第一天开始将安全性转移。 这使得组织能够过渡到 DevSecOps 策略。

结论

对于多年来建立了传统应用程序和安全解决方案的公司来说，将安全性转移到 Amazon EKS 上可能是一个渐进的过程。 但将安全性重新定义为由安全团队管理和维护并由 DevOps 使用的代码有助于更快地交付服务并使其做好生产准备。

为了保护 Amazon EKS 中的南北流量，您可以利用嵌入了 NGINX App Protect WAF 的 NGINX Ingress Controller 来防御第 7 层的点攻击，并利用 NGINX App Protect DoS 来缓解第 4 层和第 7 层的 DoS 攻击。

要尝试 NGINX Ingress Controller 与 NGINX App Protect WAF，请在AWS Marketplace上开始30 天免费试用，或联系我们讨论您的使用案例。

要了解如何使用 NGINX Ingress Controller 和 NGINX App Protect WAF 以及 Amazon EKS 上的 DoS 来防止安全漏洞并大规模保护您的 Kubernetes 应用程序，请下载我们的电子书《使用 F5 NGINX 为您的 Amazon EKS 增加安全性》 。

要详细了解 NGINX App Protect WAF 如何胜过 AWS、Azure 和 Cloudflare 的原生 WAF，请下载 GigaOm 的高性能 Webapplication防火墙测试报告，并注册参加 12 月 6 日的网络研讨会，GigaOm 分析师 Jake Dolezal 将在会上审查结果。