企业深知他们需要快速地将服务和应用推向市场，因为如果他们不这样做，竞争对手也肯定会这样做。但是 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 charts或 NGINX 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 
    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 天免费试用版或与我们联系以讨论您的用例。