Introduction:
open-appsec WAF is based on a machine-learning-engine which allows it to prevent both, known and even unknown attacks automatically, without requiring any signatures, opposite to traditional WAF solutions which are built mainly based on static signatures and therefore by design unable to prevent zero-day attacks.
open-appsec can be deployed on all typical platforms, from containerized platforms like K8s and Docker to Linux. As an open-source security solution, open-appsec can be easily integrated with many popular Reverse Proxy, API Gateway and Ingress Controller solutions, like NGINX / Ingress NGINX, Kong, APISIX, Envoy, NGINX Proxy Manager, SWAG, Istio Ingress Gateway (soon) and others.
Since its initial release in 2022, open-appsec gives users the choice to manage and monitor open-appsec either from a central Web UI (SaaS) or locally via custom resources/annotations (Kubernetes) or declarative configuration file (Docker and Linux).
Today we are excited to announce the availability of significant enhancements for managing the custom-resource-based configuration of open-appsec in Kubernetes environments as well as the declarative configuration for open-appsec on Docker/Linux platforms!
We released the new version v1beta2 schema for the local configuration file and K8s Custom Resource Definitions (CRDs) for open-appsec which can be used for declarative management of open-appsec WAF, e.g. in GitOps CD scenarios or when local management is required for some other reason like compliance regulations.
In the following blog, we will explain what’s new for both, Kubernetes, as well as Linux/Docker-based deployments.
What’s new in open-appsec configuration file/CRD schema version v1beta2
Linux and Docker:
Significantly enhanced options in the different configuration objects (practices, exceptions, etc.), providing more granular configuration as well as new configuration options that so far have only been available through the central Web UI (SaaS) (e.g. allowing declarative configuration of newly introduced rate limiting functionality)
ThreatPreventionPractice:
This is used for threat prevention configuration and contains everything from practice in v1beta1 local configuration file schema and more.
Examples: WAF, IPS, AntiBot, Snort, API Schema Enforcement, etc.
AccessControlPractice:
In this practice you can define access control-specific configuration.
Used for: Rate Limiting
For details on v1beta2-schema-based local configuration for Linux and Docker see docs here.
Kubernetes:
Significantly updated and enhanced configuration options in the different CRDs (practices, exceptions, etc.), providing both, more granular configuration options and also aligning with configuration options that have recently been added to the central Web UI (SaaS) recently (e.g. allowing declarative configuration of rate limiting functionality).
ThreatPreventionPractice:
This is used for threat prevention configuration and contains everything from practice in v1beta1 CRD and more.
Examples: WAF, IPS, AntiBot, Snort, API Schema Enforcement, etc.
AccessControlPractice:
In this practice you can define access control-specific configuration.
Used for: Rate Limiting
A new helm-based deployment flow for open-appsec on Kubernetes providing more flexibility
This new deployment flow is especially useful for declaratively managed deployments (GitOps-CD-style).
Full Kubernetes deployment instructions are available here:
Here are the main steps of this new deployment flow in short, with the main changes being the separation of open-appsec deployment, CRD deployment and deployment of the custom resources for the initial configuration:
1. Install Helm Chart for open-appsec WAF deployment integrated with the Ingress/Proxy/API Gateway solution of your choice:
Currently available open-appsec integrations for Kubernetes:
Ingress NGINX, Kong API Gateway, APISIX API Gateway, Istio Ingress Gateway (soon), Envoy Gateway (soon), Emissary Ingress (soon)…
You can now freely choose the CRD version of your choice, allowing you to use e.g. latest version or also older CRD version if e.g. you want to continue using existing custom resources created in v1beta1 version, which you don't want to migrate to the new version just yet. The latest version, currently v1beta2, is recommended in most cases.
You can start with the default configuration we offer or directly define and deploy your own custom resources for open-appsec local, declarative management.
Note that if you are not interested in GitOps-CD-style, declarative management of open-appsec, you can of course also centrally manage your deployment from our Web UI (SaaS)
Improvements providing additional flexibility especially (but not only) for large scale deployments
Introduction of “appsec class” property for assigning separate custom resources to specific deployments:
You can now have multiple sets of custom resources for the configuration of different, parallel open-appsec deployments on the same Kubernetes cluster. You can link each custom resource using the new, optional appsecClassName property with one of your open-appsec deployments, set to listen to that same, specific appsecClassName.
For full details on using “appsec class” see docs.
Introduction of namespace-scoped CRDs as optional alternative to the cluster-scoped CRDs:
If you, or your customers (in case you are e.g. an MSSP) might only have access to a dedicated namespace in a given Kubernetes cluster, you can now create and manage the open-appsec configuration in that specific namespace by using the new namespace-scoped CRDs.
In the latest v1beta2 CRD version every custom resource now exists in two versions, one which is "cluster-scoped" and one which is "namespaced". They have basically the same name, but the namespaced version always has additional suffix “NS” indicating that it's “NameSpaced”, for example:
- To define cluster-scoped custom resources for defining an open-appsec policy, use kind: Policy
- To define namespace-scoped custom resources for defining an open-appsec policy, use kind: PolicyNS
For full details on using “namespace-scoped CRDs” see docs.
Introduction of a new “policyActivation” CRD:
Using the new “policyActivation” CRD you can now declaratively assign and manage a configuration for your open-appsec deployment on K8s also in the following, previously unsupported cases:
Your reverse proxy/API gateway solution does not include ingress controller functionality (supporting “Ingress API”)
Your reverse proxy/API gateway solution does support “Ingress API” resources but you decided not to use them, e.g. because you prefer using the “Gateway API” or some other vendor-specific API for defining ingress instead
You decided not to deploy that additional ingress controller functionality (e.g. you disabled the ingress controller in Kong or APISIX, which is an optional component)
For details on using “policyActivation CRD” see docs.
We hope you find these new additional and enhanced configuration options which are included in the v1beta2 schema for the local configuration file (Docker and Linux) and the CRDs (K8s) useful to provide you even more flexibility for your declaratively-managed open-appsec deployments.
If you have any feedback or questions or require some technical assistance, please let us know via info@openappsec.io.
open-appsec is an open-source project that builds on machine learning to provide pre-emptive web app & API threat protection against OWASP-Top-10 and zero-day attacks. It simplifies maintenance as there is no threat signature upkeep and exception handling, like common in many WAF solutions.
To learn more about how open-appsec works, see this White Paper and the in-depth Video Tutorial. You can also experiment with deployment in the free Playground.
