open-appsec Integration with Istio Ingress Gateway - Beta Release Now Available!

We are thrilled to announce beta support for open-appsec integration with Istio Ingress Gateway! 

In this blog you will learn how this new integration works and how to get started with deploying and using open-appsec to integrate with Istio Ingress Gateways on Kubernetes and to protect your web applications against known and unknown web attacks and api attacks effectively! 

What is Istio?  

Istio is an open-source service mesh that helps manage, secure, and monitor communication between microservices, typically running on Kubernetes. It provides powerful traffic control, observability, and security features without requiring changes to your application code. By adding a dedicated layer for service-to-service communication, Istio makes it easier to scale, troubleshoot, and secure modern distributed systems on Kubernetes. 

What is Istio Ingress Gateway?  

The Istio Ingress Gateway is a key component that manages external traffic entering the Istio service mesh. It acts as a controlled entry point, routing incoming HTTP, HTTPS, and other protocol traffic to the appropriate services within your Kubernetes cluster. Unlike a basic Kubernetes ingress controller, Istio's gateway supports advanced traffic management features like TLS termination, routing rules, and traffic shifting. This allows you to enforce fine-grained control, security, and observability at the edge of your service mesh. Istio Ingress Gateway is based on Envoy Proxy.  The following diagram shows how Istio and Istio Ingress Gateway play together: 

What is open-appsec?  

open-appsec is an open-source, next-generation WAF solution, powered by machine learning and AI. It delivers robust protection against various web threats, including preemptive zero-day attack prevention, protection against OWASP Top 10 attack types, and more. open-appsec now integrates seamlessly into modern Kubernetes environments built with Istio Ingress Gateway and Istio Service Mesh, in addition to the already available broad compatibility with many other commonly used reverse proxy solutions such as NGINX, Envoy, Kong, APISIX, Ingress NGINX, as well as the broad platform support for Kubernetes, Docker and Linux. This makes open-appsec an ideal and highly flexible solution for protecting today’s cloud-native architectures. 

One key feature distinguishing open-appsec from traditional WAF solutions is that its threat detection capabilities are based on machine-learning technology. As it is continuously evolving and learning from malicious and benign traffic in the specific protected environment, open-appsec delivers dynamic, real-time protection not just for known, but even for zero-day attacks without requiring any manual updates or rule sets (no more signatures!). This adaptability makes it particularly effective against sophisticated attacks that can evade signature-based detection. 

For managing the configuration, open-appsec supports local, declarative configurations through custom resources in Kubernetes (or configuration files in Docker and Linux), making it fully compatible with modern CI/CD and GitOps workflows. 

In addition, open-appsec offers also an optional management WebUI (SaaS) for easy, centralized control of multiple open-appsec deployments and comfortable, comprehensive monitoring of the protected environments. 

Even when managing open-appsec locally, you can still connect to the central WebUI in a read-only mode for configuration visibility, deployment monitoring, and access to security logs with comprehensive reports and dashboards. 

Sign up for a free open-appsec WebUI tenant here: https://my.openappsec.io   

How does the integration look like? 

When installing the open-appsec helm chart for Istio to add open-appsec to your existing Istio Ingress Gateway deployment and protect it against web attacks, an open-appsec “attachment” filter is automatically added to the Envoy proxy running inside your Istio Ingress Gateway. This allows the open-appsec Agent, which is added as a separate container to each Istio Ingress Gateway pod by that same helm chart, to inspect and protect the traffic which is being handled by the Istio Ingress Gateway. 

Why is the integration of open-appsec and Istio important? 

Istio - being one of the most popular service mesh technologies used for Kubernetes these days - is designed for cloud-native applications and is therefore widely used. Istio also has reached “Graduated” maturity level as a CNCF project in 2023. Together, open-appsec and Istio enable organizations to manage, secure, and observe their web traffic communications effectively. 

With an ever-increasing attack surface traditional security tools struggle to keep up especially with distributed, cloud native architectures, necessitating solutions that are both scalable and capable of protecting the entire system effectively in real time. 

 This is where open-appsec excels, offering a highly effective, robust and preemptively protecting WAF solution tailored to protect modern, cloud native environments by integrating with Istio ingress gateway as part of Istio service mesh. 

Learn more about how open-appsec WAF technology works in the whitepaper: www.openappsec.io/whitepaper   

Check out also open-appsec’s effectiveness compared to other WAF solutions: Best WAF Solutions in 2024-2025: Real-World Comparison 

How to deploy open-appsec and integrate with Istio Ingress Gateway: 

You can find the latest official documentation for the open-appsec integration with Istio Ingress Gateway here: https://docs.openappsec.io/getting-started/start-with-kubernetes/install-using-helm-istio 

Prerequisites 

• Kubernetes 1.16.0+ cluster with RBAC enabled with Cluster admin permissions 

• Helm 3 Package Manager installed on your local machine 

• kubectl and wget command-line tools installed on the system that you use to access the Kubernetes cluster 

• An existing deployment of Istio Ingress Gateway. Supported versions: 1.23 - 1.25 

• You should understand Istio Kubernetes CRD types "Virtual Service" and "Gateway" 

• (Optional, Recommended) Sign-Up and Login to WebUI Portal If you want to centrally manage your open-appsec WAF deployment via WebUI (SaaS) OR if you want to locally manage your open-appsec WAF deployment but still connect to central WebUI for viewing the local configuration (in read-only), central monitoring, logging and reporting: Sign up and login to the WebUI available at https://my.openappsec.io. 

• (Optional, Recommended) Create a deployment profile for the open-appsec deployment in WebUI Portal If you signed-up and logged in to the WebUI Portal (see prerequisite above):  Create a new deployment profile under “Profiles” for your open-appsec deployment. Make sure to “Enforce” the new Profile you created! Once done, copy the profile token as this is needed in the installation steps further below. 

Installation 

Step 1: Add the Helm Repo 

helm repo add openappsec https://charts.openappsec.io
helm repo update 

Step 2: Deploy open-appsec Helm Chart for Istio 

Run the following command to deploy the open-appsec helm chart into your Istio Ingress Controller namespace: 

helm install open-appsec-istio openappsec/open-appsec-istio \
--set webhook.objectSelector.labelValue=istio-ingress \
--set webhook.objectSelector.labelName=app \
--set appsec.persistence.enabled=false \
--set gateways.istio-ingressgateway.service.externalTrafficPolicy=Local \
--set appsec.userEmail=<your-email-address> \
--set appsec.agentToken= \
-n [istio ingress gateway namespace] 

Make sure to replace [istio ingress gateway namespace] with the namespace name of your existing Istio ingress gateway deployment. 

If you have created a deployment profile in the WebUI (see prerequisites section above) to connect your deployment to the central WebUI please specify this token as value for the appsec.agentToken parameter (for standalone deployments leave parameter empty). 

Replace the value <your-email-address> for the appsec.userEmail parameter with your own email address, for more details on this see below. 

open-appsec will now be deployed into the existing namespace of your istio ingress gateway. 

If you have persistent storage available in your cluster, please set the "--set appsec.persistence.enabled=false" parameter in the following command to "true" to allow open-appsec to use persistent storage for the learning. This is only shown for maximum compatibility reasons below. 

Optional open-appsec helm install parameters 

• -n <istio ingress gateway namespace>: select the existing namespace name of the istio ingress gateway deployment to which open-appsec should be added and integrated with. 

The open-appsec-waf-injector uses a label in the Istio ingress gateway deployment to identify those pods, to which the open-appsec agent container should be automatically added (via mutating webhook).

In addition, it adds and loads our attachment module as a filter in the Istio ingress gateway container, allowing the open-appsec agent to inspect traffic arriving at the Istio ingress gateway.

In case of the default value an open-appsec agent container will e.g. be added to each Istio ingress gateway pod which has the following label set: app: istio-ingress 

Two parameters are available that allow you to customize the name and value of that label, if required. 

• --set webhook.objectSelector.labelName : specify the name of the label (default name is app) which is used to identify the deployment istio ingress gateway deployment to which the open-appsec attachment should be automatically injected. 

• --set webhook.objectSelector.labelValue : specify the value of the label (default is istio-ingress) which is used to identify the istio ingress gateway deployment to which the open-appsec attachment should be automatically injected.  

  
  

• --set appsec.userEmail: allows you to associate your email address with your specific deployment by replacing <your-email-address> with your own email address. This allows the open-appsec team to provide easy assistance in case of any issues you might have with your specific deployment in the future and to provide you with information proactively regarding open-appsec in general or regarding your specific deployment. This is an optional parameter and can be removed. If we send automatic e-mails, there will also be an opt-out option included for receiving similar communication in the future. 

• --set appsec.persistence.enabled: persistent volume includes machine learning information, if this is set to false then machine learning information is lost when the appsec container is stopped/restarted.  

  • true: default is true 

  • false 

  If this value is set to true (default, when not overriding with false) you must also specify appsec.persistence.learning.storageClass 

• --set appsec.persistence.learning.storageClass: Specify storage class to be used for the learning pod. Note: storageClass name specified here must support ReadWriteMany (like AWS EFS or Azure Files).

  
  

• --set appsec.agentToken: set the deployment profile token from central management WebUI (SaaS) to connect your open-appsec deployment to the central WebUI (SaaS). See here how to get the token: create a profile in web UI. If you don't set this, then your deployment will be in standalone mode.

  
  

• --set gateways.istio-ingressgateway.service.externalTrafficPolicy=Local recommended for preserving original IP address by making sure that traffic for the loadbalancer service is only routed to pods on the same node. 

  
  

For additional available configuration values please check the values.yaml within the downloaded Helm chart and the Ingress Ingress Gateways documentation available here. 

Step 3: Enable open-appsec Injection on Istio Ingress Gateway 

To allow open-appsec to inspect traffic through your Istio ingress gateway, it must be attached to the existing deployment. This happens automatically if the proper labels are set and the deployment is restarted. 

1. Label the Namespace 

Add the inject-waf-attachment=true label to the namespace of your Istio ingress gateway: 

kubectl label namespace [istio ingress gateway namespace] inject-waf-attachment="true" --overwrite 

2. Label the Deployment 

Ensure your Istio ingress deployment has the required labels as configured in your webhook.objectSelector: 

webhook.objectSelector.labelKey 

webhook.objectSelector.labelValue 

(These labels must match what’s configured in the open-appsec Helm chart. Refer to your Helm values or the section above for details.) 

3. Restart the Istio Ingress Deployment 

The restart injects the open-appsec attachment into the istio ingress gateway container, and open-appsec agent container into all existing istio ingress gateway pods, by using a Kubernetes mutating webhook to adjust the deployment. 

kubectl rollout restart deployment [istio ingress gateway deployment name] -n [istio ingress gateway namespace] 

Step 4: Validate that open-appsec is installed and running 

kubectl get pods -n [istio ingress gateway namespace] 

The READY column should show 2/2 for each istio ingress gateway pod and 1/1 for each of the following pods: waf injector, learning deployment (only in standalone deployment), shared storage deployment (only in standalone deployment).  

Step 5: If you connected to central WebUI AND configured your deployment profile in the WebUI to "This management" mode for centrally managing open-appsec configuration: 

• Create one or more assets in the WebUI which represent web applications and/or Web APIs which you want to be protected by open-appsec WAF and allows you to adjust the open-appsec configuration specifically for each of them. Make sure to link your assets to the specific WebUI Profile which you created earlier (General -> Profiles) and adjust the Threat Prevention mode to Detect-Learn or Prevent (Threat Prevention -> Mode), the steps are described here:  

Protect Additional Assets 

Don't forget to Enforce policy in the WebUI after you did any changes for those changes to become effective! 

The following steps 6-10 are only relevant if you want to locally manage this open-appsec deployment in Kubernetes using a declarative configuration using custom resources. 

They apply to the following two cases: 

• You do not want to connect to central WebUI at all (you didn't provide a deployment profile token earlier) 

• You provided deployment profile token earlier for a WebUI profile set to mode "Declarative Management" 

If you are not managing your deployment locally, scroll down to “Validate that open-appsec works” 

Step 6: (only for locally-managed deployments) Download the yaml file for open-appsec CRD installation 

Run the following command to obtain the yaml file containing the open-appsec CRD definitions, choose the CRD version you want to use. v1beta2 CRDs: 

wget https://raw.githubusercontent.com/openappsec/openappsec/main/config/crds/open-appsec-crd-v1beta2.yaml 

Step 7: (only for locally-managed deployments) Create the open-appsec CRDs which add new K8s resource-types that will be used later for defining the protection policies, log settings, exceptions, user response and more. 

You can skip this step if you skipped the previous step, because you plan to centrally manage open-appsec from central WebUI and not manage it locally using CRDs. 

Deploy the CRDs using the following command: 

For the v1beta2 CRDs: 

kubectl apply -f ./open-appsec-crd-v1beta2.yaml 

Step 8: (only for locally-managed deployments) Download a default configuration for the open-appsec custom resources 

Run the following command to obtain the yaml file containing the open-appsec default configuration custom resources, chose the CRD version which you have deployed in the steps above on your cluster. Default configuration for v1beta2 in detect-learn mode: 

wget https://raw.githubusercontent.com/openappsec/openappsec/main/config/k8s/v1beta2/open-appsec-k8s-default-config-v1beta2.yaml 

The default configuration files provided above are set to detect-learn mode, which is recommended for new deployments to allow the machine learning engine sufficient learning before moving to prevent-learn mode. You can then later easily reconfigure the open-appsec-best-practice-policy custom policy resource to prevent-learn mode. If you would like to start in prevent-learn mode in non-critical environment for testing purposes right away, you can alternatively use these files, which are preconfigured to prevent-learn mode: 

Default configuration for v1beta2 (beta) in prevent-learn mode 

wget https://raw.githubusercontent.com/openappsec/openappsec/main/config/k8s/v1beta2/open-appsec-k8s-prevent-config-v1beta2.yaml  

Step 9: (only for locally-managed deployments) Deploy default configuration for the open-appsec custom resources 

To deploy the default configuration for the open-appsec custom resources perform the step below: Default configuration for v1beta2 (beta): 

kubectl apply -f ./open-appsec-k8s-default-config-v1beta2.yaml 

Step 10: Configure open-appsec protection using custom resources (only relevant for locally-managed deployments)  

a. Make sure to have an open-appsec Policy resource 

If you followed the steps above you should now have an open-appsec-best-practice-policy custom resource deployed on your K8s cluster. You can check this with the following command which will list all open-appsec policy custom resources: 

kubectl get policies.openappsec.io 

If you want to check if it's set to detect-learn (default) or prevent-learn mode you can use this command (the name of the policy created by the default configuration in v1beta2 is default-policy): 

kubectl get policies.openappsec.io default-policy -o yaml 

If you want to create your own custom policy, you find all details here: 

For v1beta2 CRDs: Configuration Using CRDs - v1beta2 

b. Create a PolicyActivation resource Using a PolicyActivation custom resource you can now specify that your existing open-appsec policy (e.g. default-policy, see above) should be applied to all traffic matching the hostname example.com. (You can have multiple Policy custom resources and also multiple PolicyActivation custom resources) 

Create a new file policy-activation.yaml to specify a new PolicyActivation custom resource similar to the below specification (change example.com to your own hostname, adjust default-policy if you want to reference another Policy custom resource instead of the default one): 

apiVersion: openappsec.io/v1beta2 
kind: PolicyActivation
metadata:
  name: policy-activation-example
spec:
  enabledPolicies:
    - name: default-policy
      hosts:
        - "example.com"  

Then apply it to your Kubernetes cluster using: 

kubectl apply -f policyactivation.yaml 

If you want to create your own PolicyActivation custom resource, you find all details here: 

For v1beta2 CRDs: Configuration Using CRDs - v1beta2 

Validate that open-appsec works 

1. Generate some traffic to one of the services defined by your Istio Gateway and VirtualService resources.  The following command should trigger an open-appsec security log in detect or prevent (based on your configuration):

curl http://[public-hostname-in-your-istio-gateway-resource]?shell_cmd=cat/etc/passwd -v 

2. Run this command to see logs: 

Note the name of an Istio ingress gateway pod by running: 

kubectl get pods -n [istio ingress gateway namespace] 

Then show the logs of the open-appsec agent container by running: 

kubectl logs [istio ingress gateway pod name] -c open-appsec -n appsec 

If you connected your deployment to the central open-appsec web UI (SaaS), available at my.openappsec.io, you can also see the resulting security events in the Monitoring section.

Congratulations, your Istio ingress gateway is now protected with open-appsec (in detect or prevent mode)! 

---

More information is available here: open-appsec WAF:

Website: https://www.openappsec.io 

GitHub: https://github.com/openappsec 

Docs: https://docs.openappsec.io 

Playground: https://www.openappsec.io/playground 

Blogs: https://www.openappsec.io/blogs 

Istio / Istio Ingress Gateway:

Istio project: https://www.istio.io 

Istio Ingress Gateway: Istio / Ingress Gateways 

Source: https://github.com/istio