点赞
评论
收藏
分享
举报
使用 NGINX App Protect 保护 Kubernetes 中的应用
发表于2020-12-24 16:52

浏览 324

企业深知他们需要快速地将服务和应用推向市场,因为如果他们不这样做,竞争对手也肯定会这样做。但是 Web 应用是网络攻击的首要目标,盲目的快速更新只会加剧潜在安全漏洞成功通过 QA 并进入生产的风险。

受诸多因素的影响,企业很难始终遵守严格的安全标准。快速将代码发布到生产环境的压力导致安全性常常被忽视。过度依赖漏洞扫描程序等自动化工具是很危险的,因为它们并非能发现所有问题。结合使用不同跨职能开发团队提供的代码的做法导致安全管理责任分工不够明确。在生产环境中运行多个应用和应用版本会引入更多漏洞。

这最终导致对 Web 应用防火墙 (WAF) 等安全工具的需求变得前所未有得迫切。这些安全工具通常与负载均衡代理相集成,并部署在公司网络的边缘(或前门)以打造安全的边界。


现代应用和基础架构的安全漏洞揭示了该方法亟需两方面的改进:

• 边界保护力度不足。几乎没有易于保护的边界,必须将基于代理的安全工具(例如 WAF)部署在更靠近其要保护的应用的位置。

• 安全性不再只是首席信息安全官和 SecOps 团队的关注点。DevOps 团队在验收、测试和部署安全策略(作为其 CI/CD 流水线的一部分)方面扮演着至关重要的角色。


带有 NGINX App Protect 的 NGINX Plus Ingress Controller

借助 NGINX Plus Ingress Controller for Kubernetes 版本 1.8.0,您可以将 NGINX App Protect WAF 嵌入到 Ingress Controller中:

如欲将 NGINX App Protect内置到 NGINX Plus Ingress Controller中,您必须同时订阅 NGINX Plus 和 App Protect。只需几步即可轻松构建集成的 NGINX Plus Ingress Controller镜像(Docker 容器)。您可以在受支持的平台(包括 Red Hat OpenShift)上使用 Helm ChartNGINX Ingress Operator 手动部署镜像。然后,您可以使用熟悉的 Kubernetes API 管理安全策略和配置。


为什么将 WAF 集成到 Ingress Controller中至关重要?

将 WAF 集成到 Ingress Controller中可带来三个独特的优势:

• 保护应用边界 – 在架构合理的 Kubernetes 部署中,Ingress Controller是数据平面流量流向 Kubernetes 内所运行服务的唯一入口点,这使其成为部署安全代理的理想位置。

• 整合数据平面 – 将 WAF 嵌入到 Ingress Controller中消除了对单独 WAF 设备的需求。这可以降低复杂性、成本和故障点的数量。

• 整合控制平面 – WAF 配置现在可以使用 Kubernetes API 进行管理,这有助于更轻松地实现 CI/CD 流程的自动化。NGINX Plus Ingress Controller配置符合 Kubernetes 基于角色的访问控制 (RBAC) 惯例,因此您可以将 WAF 配置安全地委派给专门的 DevSecOps 团队。

App Protect 的配置对象在 Ingress Controller(使用 YAML 文件)和 NGINX Plus(使用 JSON )之间保持一致。主配置可轻松迁移并部署到任一设备上,这有助于更轻松地将 WAF 配置作为代码进行管理并将其部署到任何应用环境中。


在 NGINX Plus Ingress Controller中配置 App Protect

您可以使用两种新自定义资源在 NGINX Plus Ingress Controller中配置 App Protect:

  • • APPolicy 定义了 App Protect 应用的 WAF 策略。WAF 策略是独立的 App Protect JSON 格式的策略的 YAML 版本。
  • • APLogConf 定义了 App Protect 模块的日志记录行为。

Ingress Controller镜像还包含一个在构建时嵌入的 App Protect 签名集。

部署合适的 APPolicy 和 APLogConf 资源后,您可以使用一组注释从 Kubernetes Ingress 资源中引用它们:

apiVersion: extensions/v1beta 

kind: Ingress 

metadata: 

  name: cafe-ingress 

  annotations: 

    kubernetes.io/ingress.class: “nginx” 

    appprotect.f5.com/app-protect-policy: "default/dataguard-alarm" 

    appprotect.f5.com/app-protect-enable: "True" 

    appprotect.f5.com/app-protect-security-log-enable: "True" 

    appprotect.f5.com/app-protect-security-log: "default/logconf" 

    appprotect.f5.com/app-protect-security-log-destination: "syslog:server=10.27.2.34:514" 

spec: 

  ...


然后,AppProtect 会检查并可能阻止由 Ingress Controller处理的所有请求。

可以在不同的命名空间(可能由 DevSecOps 团队拥有)中对 APPolicy 和 APLogConf 资源进行定义。这可以安全、可靠地隔离问题,例如在大型企业中,将安全策略委派给专门团队。

App Protect 策略可保护 Web 应用免受多种类型的威胁,包括 OWASP Top 10、跨站点脚本编写 (XSS)、注入、绕过技术、信息泄漏(使用 Data Guard)等。以下为 APPolicy 自定义资源启用 Data Guard 违规拦截模式的示例。

apiVersion: appprotect.f5.com/v1beta1 

kind: APPolicy 

metadata:  

  name: dataguard-alarm 

spec: 

  policy: 

    applicationLanguage: utf-8 

    blocking-settings: 

      violations: 

      - alarm: true 

        block: true 

        name: VIOL_DATA_GUARD 

    > 

      creditCardNumbers: true 

      enabled: true 

      enforcementMode: ignore-urls-in-list 

      maskData: true 

      usSocialSecurityNumbers: true 

    enforcementMode: blocking

    name: dataguard-alarm 

    template:

     name: POLICY_TEMPLATE_NGINX_BASE


日志记录

App Protect 和 NGINX Plus Ingress Controller的日志在设计上是分开的,旨在反映安全团队通常如何独立于 DevOps 和应用所有者运作。通过将参数设置为 app-protect-security-log-destination(系统日志 Pod 的集群 IP 地址注释),您可以将 App Protect 日志发送给从 Kubernetes Pod 可访问的任何 syslog 目的地。(请参见上述 Ingress 资源示例)。此外,您还可以使用 APLogConf 资源指定您关心的 App Protect 日志,并隐式指定将哪些日志推送到 syslog Pod 中。对于所有 Kubernetes 容器,NGINX Plus Ingress Controller日志都会转发到本地标准输出。


资源阈值

最后,Ingress Controller上的 NGINX App Protect 为 App Protect 进程的 CPU 和内存利用率提供可配置的资源保护阈值,以防止它们耗尽其他进程。这在 Kubernetes 等多租户环境中尤其重要,此类环境依赖于资源共享,可能会受到“坏邻居效应 (noisy neighbor)”问题的困扰。以下是 ConfigMap 为 App Protect 进程设置资源阈值的示例。

kind: ConfigMap 

apiVersion: v1 

metadata: 

  name: nginx-config 

  namespace: nginx-ingress 

data: 

  app_protect_physical_memory_util_thresholds: "high=100 low=10" 

  app_protect_cpu_thresholds: "high=100 low=50" 

  app_protect_failure_mode_action: "drop"


高阈值设置 App Protect 进入故障模式时的利用率,低阈值设置其退出故障模式时的利用率。对于内存利用率,它们分别为 100% 和 10%,而对于 CPU,它们分别为 100% 和 50%。drop for app_protect_failure_mode_action 数值表示 App Protect 在故障模式下通过关闭连接来拒绝流量。

有关在 NGINX Plus Ingress Controller中对 NGINX App Protect 进行配置和故障排除的更多详细信息,请参阅 Ingress Controller文档。有关其他 App Protect 用例的信息,请参阅 NGINX App Protect 文档。


未来整合

版本 1.8.0 中的 Ingress 资源配置使用注释来引用 App Protect 策略,该策略无法理想地控制检查或不检查哪些请求。

在 NGINX Plus Ingress Controller的未来版本中,您可以看到与 NGINX Ingress 资源相集成的更详细的可自定义配置。这支持就如何对请求应用 WAF 策略实施附加控制。


结语

对于现代容器化应用,通常可以假定所有入口流量(“南北”)都不可信,而内部生成的流量(“东西向”)都格式正确且可信。在这种情况下,Ingress Controller是部署 WAF 等安全代理的理想位置。

带有 NGINX App Protect 的 NGINX Plus Ingress Controller是唯一与完全受支持的 WAF 相集成的 Ingress Controller实现。通过整合数据平面设备,并利用 Kubernetes API 进行配置,可进一步提高将 WAF 嵌入到 Ingress Controller中的效率。

如欲试用带有 NGINX App Protect 的 NGINX Plus Ingress Controller,请立即下载 30 天免费试用版与我们联系以讨论您的用例




已修改于2023-03-06 02:26
本作品系原创
创作不易,留下一份鼓励
NGINX官方账号

暂无个人介绍

关注



写下您的评论
发表评论
全部评论(0)

按点赞数排序

按时间排序

关于作者
NGINX官方账号
这家伙很懒还未留下介绍~
171
文章
21
问答
180
粉丝
相关文章
转载:http://www.siwei.me/blog/posts/nginx-debug-nginx-debugging-logreferto:  http://nginx.org/en/docs/debugging_log.html1.默认是不带这个特性的。需要重新编译安装: ./configure--with-debug... 然后在error_logdirective中,使用:error_log/path/to/logdebug; 注意,如果在下层配置文件中,重新定义了error_log,那么会覆盖掉上级的debug配置,例如:error_log/path/to/logdebug; http{ server{ error_log/path/to/log;#这里会使上面的debug输出失效。 error_log/path/to/logdebug;#应该这样。 ...
点赞 2
浏览 493
概述上篇我们讲述了NGINX缓存的原理以及NGINX的CacheLoader和CacheManager进程是如何工作的。本篇,我们继续分析NGINX工作原理的剩余的两个部分,那就是NGINX是如何生成和使用缓存的。引用上篇文章中的图片来描述从高层次来看,NGINX缓存的大体结构。 如上图所示,NGINX在内存中维护一棵红黑树,然后每一个节点上存储这文件的元数据(meta data),并且在磁盘中存放文件的完整内容。NGINX的缓存功能都是围绕上述数据结构进行的。主要包括以下四个任务:1.
点赞 5
浏览 1.2k
Kubernetes已成为容器化应用系统受到在其生产环境中。在本博文中,我们通过NGINXIngressControllerforKubernetes 并三个指标性能测试的结果介绍 NGINX和Kubernetes 决定应用。中wrk 40Gb到。Controller静态内容NGINXWeb服务器以下的硬件计算机网络客户端1个英特尔XL71040GbEQSFP+主要节点1个英特尔XL71040GbEQSFP+辅助节点1个英特尔10GbX540AT2所用软件用 版本4.1.0,按照相关取自 版本1.4.3(包括NGINX开源版本1.15.8 版本1.13.1全OpenSSL版本1.1.0gFlannel我们运行了测试三项性能指标: ●  每秒可处理的请求数(取固定时间段内平均值)。的Controller将请求代理到上游Pod,以获取客户端请求的静态内容。静态内容是一个。每秒SSL/TLS事务(TPS) Controller支
点赞 0
浏览 425