Securing Your Apps in Kubernetes with NGINX App Protect

Original: https://www.nginx.com/blog/securing-apps-in-kubernetes-nginx-app-protect/

Businesses know they need to bring services and applications to market quickly because if they don’t, a competitor surely will. But web applications are prime targets for cyberattacks, and updating them fast and furiously increases the risk that potential security vulnerabilities slip through QA and make their way into production.

Many factors make it challenging to consistently apply strong security standards. The pressure to release code quickly into production makes it tempting to let security slide. Over‑reliance on automated tools such as vulnerability scanners is dangerous, because they don’t catch every issue. Combining code contributed by various cross‑functional dev teams makes it less clear who is responsible for enforcing security. Running multiple applications and application versions in production multiplies the chinks in your applications’s armor.

The net result is that the need for security tools such as web application firewalls (WAFs) has never been more acute. These security tools are often integrated with a load‑balancing proxy, and deployed at the edge (or front door) of a corporate network to create a secure perimeter.

Security breaches of modern applications and infrastructures have revealed two necessary refinements to this approach:

The NGINX Plus Ingress Controller with NGINX App Protect

With NGINX Plus Ingress Controller for Kubernetes release 1.8.0, you can embed the NGINX App Protect WAF in the Ingress Controller:

To build NGINX App Protect into the NGINX Plus Ingress Controller, you must have subscriptions for both NGINX Plus and App Protect. A few simple steps are all it takes to build the integrated NGINX Plus Ingress Controller image (Docker container). You can deploy the image manually, with Helm charts, or with the NGINX Ingress Operator on supported platforms including Red Hat OpenShift. You then manage security policies and configuration using the familiar Kubernetes API.

Why Is Integrating the WAF into the Ingress Controller So Significant?

Integrating the WAF into the Ingress Controller brings three unique benefits:

The configuration objects for App Protect are consistent across both the Ingress Controller (using YAML files) and NGINX Plus (using JSON). A master configuration can easily be translated and deployed to either device, making it even easier to manage WAF configuration as code and deploy it to any application environment.

Configuring App Protect in the NGINX Plus Ingress Controller

You configure App Protect in the NGINX Plus Ingress Controller with two new custom resources:

The Ingress Controller image also includes an App Protect signature set, which is embedded at build time.

Once you have deployed suitable APPolicy and APLogConf resources, you reference them from a Kubernetes Ingress resource, using a set of Annotations:

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 then inspects and potentially blocks all requests handled by the Ingress controller.

The APPolicy and APLogConf resources can be defined in a different namespace, perhaps one that is owned by the DevSecOps team. This allows for safe and secure separation of concerns, for example in larger enterprises that delegate security policies to a dedicated team.

App Protect policies protect your web applications against many types of threat, including the OWASP Top 10, cross‑site scripting (XSS), injections, evasion techniques, information leakage (with Data Guard), and much more. The following sample APPolicy custom resource enables Data Guard violation in blocking mode.

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

Logging

The logs for App Protect and the NGINX Plus Ingress Controller are separate by design, to reflect how security teams usually operate independently of DevOps and application owners. You can send App Protect logs to any syslog destination that is reachable from the Kubernetes Pods, by setting the parameter to the app-protect-security-log-destination Annotation to the cluster IP address of the syslog Pod (see the Ingress resource above for an example). Additionally, you can use the APLogConf resource to specify which App Protect logs you care about, and by implication which logs are pushed to the syslog Pod. The NGINX Plus Ingress Controller logs are forwarded to the local standard output, as for all Kubernetes containers.

Resource Thresholds

Lastly, NGINX App Protect on the Ingress Controller provides configurable resource protection thresholds for both CPU and memory utilization by the App Protect processes, to keep them from starving other processes. This is particularly important in multi‑tenant environments such as Kubernetes which rely on resource sharing and can potentially suffer from the ‘noisy neighbor’ problem. The following sample ConfigMap sets resource thresholds for App Protect processes. 

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"

The high threshold sets the percentage utilization at which App Protect enters failure mode, and the low threshold the utilization at which it exits failure mode. For memory utilization these are 100% and 10% respectively, while for CPU they are 100% and 50%. The value drop for app_protect_failure_mode_action means that App Protect rejects traffic while in failure mode, by closing the connection.

For more detailed information on configuring and troubleshooting NGINX App Protect in the NGINX Plus Ingress Controller, see the Ingress Controller documentation. For information about other App Protect use cases, see the NGINX App Protect documentation.

Future Integration

The Ingress resource configuration in release 1.8.0 uses Annotations to reference App Protect policies, which doesn’t provide ideally granular control over which requests are inspected and which are not.

In a future release of NGINX Plus Ingress Controller, you can expect to see more detailed, customizable configuration that is integrated with the NGINX Ingress Resources. This will allow for additional control over how WAF policies are applied to requests.

Conclusion

For modern, containerized applications, it’s often safe to assume that that all ingress traffic (“north‑south”) is untrusted, whereas internally generated traffic (“east‑west”) is well‑formed and trustworthy. In this case, the Ingress Controller is an ideal location for a security proxy such as a WAF.

The NGINX Plus Ingress Controller with NGINX App Protect is the only Ingress Controller implementation that integrates a fully supported WAF. Embedding the WAF in the Ingress Controller further improves efficiencies by consolidating data‑plane devices into one, and by leveraging the Kubernetes API for its configuration.

To try NGINX App Protect with the NGINX Plus Ingress Controller, start your free 30-day trial today or contact us to discuss your use cases.

Retrieved by Nick Shadrin from nginx.com website.