借助Amazon EKS上的F5 NGINX App Protect实现安全左移

Fabrizio FiorucciNGINX解决方案架构师 | F5 (EMEA)

Thelen Blum高级产品营销经理，NGINX App Protect | F5

根据F5发布的《2022年应用策略现状》报告，全球企业数字化转型持续加速。大多数企业部署了200至1,000个应用，分布在多个云区域。如今，应用正从单体架构转向现代分布式架构。

Kubernetes于2016年开始进入主流技术应用领域，距今仅6年。然而，如今全球已有超过75%的组织在生产环境中运行容器化应用，较2019年增长30%。在包括Amazon Elastic Kubernetes Service (EKS)在内的Kubernetes环境中，安全性是一项关键问题。安全措施往往到应用开发流程的最后阶段才被附加，有时甚至要等到容器化应用启动并运行后才会实施。

在 COVID‑19 疫情的推动下，当前的数字化转型浪潮促使许多企业采用更全面的安全方法，并考虑实施“左移”策略。安全左移是指在软件开发生命周期（SDLC）的早期阶段引入安全措施，并在应用、容器、微服务和 API 的 CI/CD 流水线各个阶段使用安全工具和控制措施。这标志着向 DevSecOps 新范式转变，即将安全融入 DevOps 流程，并与现代软件应用开发和交付中常见的快速发布周期相结合。

DevSecOps代表着重大的文化转变。安全团队和DevOps团队以共同目标开展协作：快速、安全地将高质量产品推向市场。开发人员不再处处受阻于中断工作流程的安全程序，安全团队也不再需要反复修复相同的问题。这样，组织便能保持稳健的安全态势，及时发现并防止漏洞、错误配置以及违反合规要求或政策的行为。

将安全左移并以代码形式实现安全自动化，有助于从一开始就保护Amazon EKS环境。了解如何实现大规模生产就绪，是构建Kubernetes基础的重要一环。对Amazon EKS实施适当治理，有助于提高整个企业的效率、透明度和问责能力，同时控制成本。完善的治理和安全护栏可构建一个框架，提升集群的可见性和可控性。如果缺少这些措施，贵组织将面临更高的安全漏洞风险，以及收入和声誉受损所带来的长期成本。

要进一步了解转向安全优先战略时需要考虑的事项，请参阅O’Reilly近期发布的这份报告《应用安全左移》。

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

自动化是实现DevSecOps的重要推动因素，即使开发和部署节奏很快，也有助于保持一致性。与基础设施即代码类似，采用安全即代码方法实现自动化，需要使用声明式策略来维持所需的安全状态。

GitOps是一种有助于实现自动化的运维框架，可支持并简化应用交付和集群管理。GitOps的核心理念是使用Git存储库，以代码形式存储Kubernetes对象以及在Kubernetes上运行的应用的声明式策略。自动化流程是GitOps范式的最后一环，可使生产环境与所有已存储的状态描述保持一致。

该存储库以安全策略的形式作为单一事实来源，随后，声明式配置即代码描述会在CI/CD流水线流程中引用这些策略。例如，NGINX维护着一个包含F5 NGINX App Protect Ansible角色的GitHub存储库，希望能帮助有意将安全左移的团队。

借助这样的代码仓库，只需更新仓库，即可部署新应用或更新现有应用。其余工作均由自动化流程处理，包括应用配置并确保更新成功。这样，开发人员的所有操作都在版本控制系统中完成并保持同步，从而对业务关键型应用实施安全防护。

在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 and 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十大攻击，并提供高级特征码和威胁防护、机器人防御，以及Dataguard防护，防止个人身份信息（PII）遭到利用。NGINX App Protect DoS在第4层和第7层提供额外防线，利用用户行为分析和应用健康检查来缓解复杂的应用层DoS攻击，防御的攻击包括Slow POST、Slowloris、洪泛攻击和Challenger Collapsar。

此类安全措施可保护REST API以及通过Web浏览器访问的应用。API安全策略也会沿南北向流量在Ingress层实施。

配备NGINX App Protect WAF和DoS防护的NGINX Ingress Controller可按请求而非按服务保护Amazon EKS流量：这种方式能更有效地洞察第7层流量，也更有助于实施SLA和南北向WAF安全防护。

GigaOm最新发布的《高性能Web应用防火墙测试》报告显示，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错误）且每个请求的延迟低于30 ms时所达到的最高吞吐量。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的日志。与所有Kubernetes容器一样，NGINX Ingress Controller日志会转发到本地标准输出。

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

apiVersion: appprotect.f5.com/v1beta1 kind: APLogConf 
metadata: 
 name: logconf 
 namespace: dvwa 
spec: 
 content: 
   format: default 
   max_message_size: 64k 
   max_request_size: any 
 filter: 
   request_type: all

使用NGINX CRD定义WAF策略

The APPolicy Policy对象是一种CRD，采用声明式方法，通过签名集和安全规则定义WAF安全策略。此方法同时适用于NGINX App Protect WAF和DoS，以下示例重点介绍WAF。策略定义通常作为SecOps目录的一部分，存储在组织的权威数据源中。

apiVersion: appprotect.f5.com/v1beta1 kind: APPolicy 
metadata: 
  name: sample-policy
spec: 
  policy: 
    name: sample-policy 
    template: 
      name: POLICY_TEMPLATE_NGINX_BASE 
    applicationLanguage: utf-8 
    enforcementMode: blocking 
    signature-sets: 
    - name: Command Execution Signatures 
      alarm: true 
      block: true
[...]

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

apiVersion: appprotect.f5.com/v1beta1 kind: APLogConf 
metadata: 
  name: log-violations
spec: 
  content: 
    format: default 
    max_message_size: 64k 
    max_request_size: any 
  filter: 
    request_type: illegal

随后，waf-policy策略对象会引用sample-policy，以便在NGINX Ingress Controller公开应用时，由NGINX App Protect WAF对传入流量强制执行该策略。该对象还会引用log-violations，用于定义发送到logDest字段所指定syslog服务器的日志条目格式。

apiVersion: k8s.nginx.org/v1 kind: Policy 
metadata: 
  name: waf-policy 
spec: 
  waf: 
    enable: true 
    apPolicy: "default/sample-policy" 
    securityLog: 
      enable: true 
      apLogConf: "default/log-violations" 
      logDest: "syslog:server=10.105.238.128:5144"

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

apiVersion: k8s.nginx.org/v1kind: VirtualServer
metadata:
  name: eshop-vs
spec:
  host: eshop.lab.local
  policies:
  - name: default/waf-policy
  upstreams:
  - name: eshop-upstream
    service: eshop-service
    port: 80
  routes:
  - path: /
    action:
      pass: 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 App Protect WAF的NGINX Ingress Controller，请在AWS Marketplace开始30天免费试用，或联系我们，讨论您的用例。

要了解如何在Amazon EKS上使用NGINX Ingress Controller、NGINX App Protect WAF和DoS大规模防范安全漏洞并保护Kubernetes应用，请下载我们的电子书《使用F5 NGINX增强Amazon EKS的安全性》。

要详细了解NGINX App Protect WAF与AWS、Azure和Cloudflare的原生WAF相比具有哪些性能优势，请下载GigaOm发布的《高性能Web应用防火墙测试》报告，并报名参加12月6日的网络研讨会，届时GigaOm分析师Jake Dolezal将解读测试结果。

关于作者

Fabrizio FiorucciNGINX解决方案架构师 | F5 (EMEA)

Fabrizio Fiorucci 的更多博客文章

Thelen Blum高级产品营销经理，NGINX App Protect | F5

Thelen Blum 的更多博客文章