open-appsec
WebsiteManagement PortalPlaygroundGitHub
  • open-appsec Documentation
  • What is open-appsec?
  • open-appsec Video Tutorials
  • Release Notes
  • Getting started
    • Getting Started
    • Start With Kubernetes
      • Install Using Interactive CLI Tool (Ingress NGINX)
      • Configuration Using Interactive CLI Tool
      • Install Using Helm
      • Install Using Helm - new flow (beta)
      • Configuration Using CRDs
      • Configuration Using CRDs - v1beta2
      • Configuration using CRDs - special options for Large Scale Deployments
        • Using appsec class for assigning separate custom resources to specific deployments
        • Using namespace-scoped custom resources
      • Monitor Events
    • Start With Linux
      • Install open-appsec for Linux
      • Using the open-appsec-ctl Tool
      • Configuration Using Local Policy File (Linux)
      • Local Policy File (Advanced)
      • Local Policy File v1beta2 (beta)
      • Monitor Events
    • Start with Docker
      • Install With Docker (Centrally Managed)
      • Install With Docker (Locally Managed)
      • Deploy With Docker-Compose (Beta)
      • Configuration Using Local Policy File (Docker)
      • Local Policy File (Advanced)
    • Using the Web UI (SaaS)
      • Sign-Up and Login to Portal
      • Agents Deployment
      • Connect Deployed Agents to SaaS Management Using Tool (K8s & Linux)
      • Connect Deployed Agents to SaaS Management Using Helm (K8s)
      • Connect Deployed Agents to SaaS Management (Docker)
      • Create a Profile
      • Protect Additional Assets
      • Monitor Events
    • Using the Advanced Machine Learning Model
  • Concepts
    • Agents
    • Management & Automation
    • Security Practices
    • Contextual Machine Learning
  • SETUP INSTRUCTIONS
    • Setup Web Application Settings
    • Setup Custom Rules and Exceptions
    • Setup Web User Response Pages
    • Setup Log Triggers
    • Setup Behavior Upon Failure
    • Setup Agent Upgrade Schedule
  • Additional Security Engines
    • Anti-Bot
    • API Schema Enforcement
    • Data Loss Prevention (DLP) Rules
    • File Security
    • Intrusion Prevention System (IPS)
    • Rate Limit
  • Snort Rules
    • Import Snort Rules
    • Write Snort Signatures
  • HOW TO
    • Configuration and Learning
      • Track Learning and Move From Learn/Detect to Prevent
      • Configure Contextual Machine Learning for Best Accuracy
      • Track Learning and Local Tuning in Standalone Deployments
      • Move From Detect to Prevent in K8s With Many Ingress Rules
  • Deployment and Upgrade
    • Load the Attachment in Proxy Configuration
    • Upgrade Your Reverse Proxy/API Gateway When an Agent is Installed
    • Integration in GitOps CD (K8s)
    • Build open-appsec Based on Source Code
  • Management Web UI
    • Track Agent Status
    • Delete or Reset Management Tenant (SaaS)
    • Disconnect an open-appsec agent from Central Management
  • Integrations
    • About Integrations With 3rd Party Solutions
    • CrowdSec
      • CrowdSec Bouncer Support
      • CrowdSec Intelligence Sharing Using open-appsec Parser/Scenario
    • NGINX Proxy Manager
      • Install NGINX Proxy Manager with open-appsec managed from NPM WebUI
      • Install NGINX Proxy Manager with open-appsec managed from central WebUI (SaaS)
      • Frequently Asked Questions
      • How to Migrate from an Existing NGINX Proxy Manager Deployment and Keep Configuration
    • NPMplus
    • Docker SWAG
      • Install Docker SWAG with open-appsec (locally managed)
      • How to connect locally managed Docker SWAG with open-appsec to WebUI
      • Install Docker SWAG with open-appsec (centrally managed)
      • Deploy Docker SWAG with docker-compose (beta)
      • Frequently Asked Questions
  • Prometheus
  • Troubleshooting
    • Troubleshooting
    • Troubleshooting Guides
      • Configuration contains ingress/asset with URL which already has asset attached to it in your tenant
      • HTTP Request to Port 80 Not Returning as Expected
      • Agent Fails to Recognize HTTP Transactions with NGINX
      • Agent Not Recognizing Initial HTTP Requests
      • Handling Large Requests (413 Responses)
      • open-appsec on Docker HTTP Transaction Handler Is Set To Ready
      • Traffic Recognition Issue on Single-Core Machine/Connection Timed Out
      • Installing open-appsec on CentOS 7
      • SELinux: checking status and disabling
      • Deploy open-appsec directly on the web server hosting the application to protect
      • object is locked or remote, and therefore cannot be modified
      • Failed to Register to Fog
  • references
    • Agent CLI
    • Event Query Language
    • Events/Logs Schema
    • WAF Comparison Project
Powered by GitBook
On this page
  • Prerequisites
  • Installation

Was this helpful?

  1. Getting started
  2. Start With Kubernetes

Install Using Helm - new flow (beta)

PreviousInstall Using HelmNextConfiguration Using CRDs

Last updated 1 hour ago

Was this helpful?

The steps described here to deploy open-appsec on Kubernetes are currently in beta.

The installation flow as described here has changed from the previous one in the way that deployment of the open-appsec helm chart, CRDs and default configuration are now separate steps. This allows more flexibility and custom selection of the preferred CRD version by the user.

Prerequisites

  • Kubernetes 1.16.0+ cluster with enabled with Cluster admin permissions

  • installed on your local machine

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

  • You have understanding of Kubernetes Ingress and either have an already deployed Ingress or know how to configure one.

For more details about Kubernetes Ingress see Kubernetes documentation .

  • (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: Follow the instructions below to sign-up and login to the WebUI available at :

  • (Optional, Recommended) Create deployment profile for the open-appsec deployment in WebUI Portal If you signed-up and logged in to the WebUI Portal (see prerequisite above), now follow the instructions below to create a new deployment profile for your open-appsec deployment. Once done, don't forget to copy the profile token after policy installation as this is needed in the installation steps further below.

Installation

Step 1: Add the Helm Repo

Please note that this new installation flow with helm uses a different helm chart.

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

Step 2: Install open-appsec Helm Chart and CRDs (Custom Resource Definitions)

Run the following command to install open-appsec together with Ingress NGINX Ingress Controller, Kong API Gateway, or Apache APISIX API Gateway.

helm install open-appsec-nginx openappsec/open-appsec-nginx-ingress \
--set controller.ingressClass=appsec-nginx \
--set controller.ingressClassResource.name=appsec-nginx \
--set controller.ingressClassResource.controllerValue="k8s.io/appsec-nginx" \
--set appsec.persistence.enabled=false \
--set controller.service.externalTrafficPolicy=Local \
--set appsec.userEmail="<your-email-address>" \
--set appsec.agentToken= \
--namespace appsec --create-namespace
helm install open-appsec-kong openappsec/open-appsec-kong \
--set ingressController.ingressClass=appsec-kong \
--set appsec.persistence.enabled=false \
--set appsec.userEmail="<your-email-address>" \
--set appsec.agentToken= \
--namespace appsec --create-namespace
helm install open-appsec-apisix openappsec/open-appsec-apisix \
--set rbac.create=true \
--set service.type=LoadBalancer \
--set appsec.persistence.enabled=false \
--set ingress-controller.enabled=true \
--set ingress-controller.config.ingressClass=appsec-apisix \
--set appsec.userEmail="<your-email-address>" \
--set appsec.agentToken= \
--namespace appsec-apisix --create-namespace

Your deployment of open-appsec and the selected proxy solution for integration will be done into a new namespace appsec.

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.

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 <namespace>: select a namespace name that will include the open-appsec and NGINX ingress controller resources, please use the appsec namespace.

  • --create-namespace: create namespace if it doesn't exist

  • --name-template: name of your deployment, used for pod naming (optional)

  • --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 us to provide you easy assistance in case of any issues you might have with your specific deployment in the future and also to provide you 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 emails 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.mode: Configure if the deployment is connected to the central management WebUI (SaaS)

    • standalone: use this only for standalone deployment (locally managed via CRDs with no connection to central management WebUI (SaaS))

    • managed: use this for connection to central management WebUI (SaaS), when this is set appsec.agentToken must be provided as well.

  • --set controller.ingressClassResource.name: specify unique ingress class name, default is 'appsec-nginx'

  • --set controller.ingressClassResource.controllerValue: default is 'k8s.io/appsec-nginx'

  • --set controller.service.externalTrafficPolicy=Local required for preserving original IP address in conjunction with LoadBalancer in e.g. Azure AKS (Standard Load Balancer) or AWS EKS (Network Load Balancer).

  • -n <namespace>: select a namespace name that will include the open-appsec and Kong gateway resources, please use the appsec namespace.

  • --create-namespace: create namespace if it doesn't exist

  • --name-template: name of your deployment, used for pod naming (optional)

  • --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 us to provide you easy assistance in case of any issues you might have with your specific deployment in the future and also to provide you 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 emails 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.mode: Configure if the deployment is connected to the central management WebUI (SaaS)

    • standalone: use this only for standalone deployment (locally managed via CRDs with no connection to central management WebUI (SaaS))

    • managed: use this for connection to central management WebUI (SaaS), when this is set appsec.agentToken must be provided as well.

  • --set kind: select deployment type

    • AppSec: Installs open-appsec and Kong as K8s Deployment (default, recommended for most scenarios) Note: If required, in this mode you can also switch to Daemonset using by additionally setting deployment.daemonset to true)

    • AppSecStateful: Installs open-appsec and Kong as a K8s StatefulSet

    • Vanilla: (for debugging purposes only) installs just regular Kong based on the Helm chart without open-appsec. Note: This can be useful when debugging if a potential issue with the Kong deployment is caused by open-appsec or not.

    • NOTE: If Vanilla mode is used, then the Kong/Kong Gateway image specified under image.repository/image.tag is being used, instead of the open-appsec specific Kong/Kong Gateway image specified here: appsec.kong.image.repository / appsec.kong.image.tag

  • --set ingressController.ingressClass: specify desired ingress class name

  • -n <namespace>: select a namespace name that will include the open-appsec and Kong gateway resources, please use the appsec namespace.

  • --create-namespace: create namespace if it doesn't exist

  • --name-template: name of your deployment, used for pod naming (optional)

  • --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 us to provide you easy assistance in case of any issues you might have with your specific deployment in the future and also to provide you 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 emails 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.mode: Configure if the deployment is connected to the central management WebUI (SaaS)

    • standalone: use this only for standalone deployment (locally managed via CRDs with no connection to central management WebUI (SaaS))

    • managed: use this for connection to central management WebUI (SaaS), when this is set appsec.agentToken must be provided as well.

  • --set ingressController.ingressClass: specify desired ingress class name

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

kubectl get pods -n appsec

The READY column should show 2/2 for the ingress controller pod and 1/1 for the learning deployment and shared storage deployment pods.

kubectl get pods -n appsec

The READY column typically shows 3/3 (or 2/2 if e.g. Kong is deployed without the Kong ingress controller) for the kong pod and 1/1 for the learning deployment and shared storage deployment pods.

kubectl get pods -n appsec-apisix

The READY column should show 2/2 for the ingress controller pod and 1/1 for the learning deployment and shared storage deployment pods.

Step 4: 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 5-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"

Step 5: (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, chose the CRD version you want to use. v1beta1 CRDs:

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

v1beta2 CRDs (beta):

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

Step 6: (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, becausae you plan to centrally manage open-appsec from central WebUI and not manage it locally using CRDs.

Deploy the CRDs using the following command: If you downloaded v1beta1 CRDs:

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

If you downloaded v1beta2 CRDs: (Replace <open-appsec namespace> with the namespace to which you installed the helm chart.)

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

Step 7: (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 v1beta1 in detect-learn mode:

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

Default configuration for v1beta2 (beta) 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-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 v1beta1 in prevent-mode

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

Default configuration for v1beta2 (beta) in prevent-mode

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

Step 8: (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: Apply default configuration for v1beta1:

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

Default configuration for v1beta2 (beta):

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

Step 9: Setup options (only for locally-managed deployments)

Here's the available options:

NGINX Ingress Controller Option 1: Add protection to existing running Ingress

open-appsec implements K8s ingress resources serving as an NGINX ingress controller with multi-layered Web App & API protection functionalities.

If you use today an NGINX Ingress, you can easily update your existing K8S ingress resource to use open-appsec ingress. Once you apply the change, the ingress will reload and traffic will be protected.

This is a good approach for a lab, staging or non critical production environments. For production deployments we suggest to first run a new Ingress protected with open-appsec WAF in parallel, see instructions "NGINX Ingress Controller (2)" (next tab).

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:

kubectl get policies.openappsec.io open-appsec-best-practice-policy -o yaml

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

For v1beta1 CRDs: Configuration Using CRDs

For v1beta2 CRDs: Configuration Using CRDs - v1beta2

b. Find out the name of your relevant ingress resource:

kubectl get ing -A

c. Edit the ingress resource:

kubectl edit ing/<ingress name> -n <ingress namespace>

d. Change the ingressClassname to the ingress class name used by open-appsec:

spec:
  ingressClassName: appsec-nginx

The default ingress class name used by open-appsec is appsec-nginx. In case you configured another ingress class name, please adjust the setting accordingly.

e. Add this annotation to activate the desired open-appsec policy custom resource:

openappsec.io/policy: default-policy

Make sure to use the correct name for the open-appsec policy resource which you created above.

The default mode of the "default-policy" custom resource is detect-learn. It will not block any traffic, unless you change the policy mode to prevent-learn, either for a specific ingress rule or for the whole policy.

NGINX Ingress Controller Option 2: Run a new protected Ingress in parallel

open-appsec implements K8s ingress resources serving as an NGINX ingress controller with multi-layered Web App & API protection functionalities.

Duplicate your existing ingress rules and run a new ingress, side by side with your existing one. Once you are happy with the result, you can change your DNS setting to point to the new, protected, ingress and take down the existing ("old") ingress.

This option allows you to test that all services are properly accessible via the new ingress, without worrying about traffic disruption. If you instead prefer to directly add open-appsec to your existing ingress this is possible as well. See alternative instructions "NGINX Ingress Controller (1)" (first tab).

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:

kubectl get policies.openappsec.io open-appsec-best-practice-policy -o yaml

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

For v1beta1 CRDs: Configuration Using CRDs

For v1beta2 CRDs: Configuration Using CRDs - v1beta2

b. Find out the name of your ingress resource by running:

kubectl get ing -A

c. Duplicate your current ingress configuration:

kubectl get ingress <ingress name> -n <namespace> -o json | jq 'del(.metadata.resourceVersion,.metadata.uid,.metadata.selfLink,.metadata.creationTimestamp,.status,.metadata.generation,.metadata.ownerReferences)' | yq eval - -P  > protected-ingress.yaml

d. Edit the ingress YAML:

vi protected-ingress.yaml

e. Set a resource name for your new protected ingress, for example:

name: appsec-<existing ingress name>

f. Change the ingressClassname to use open-appsec:

ingressClassName: appsec-nginx

g. Add this annotation to activate open-appsec in detect or prevent mode:

openappsec.io/policy: open-appsec-best-practice-policy

Make sure to use the correct name for the open-appsec policy resource which you created above.

h. Apply the new ingress:

kubectl apply -f protected-ingress.yaml

The default mode of the open-appsec-best-practice-policy is detect-learn. It will not block any traffic, unless you change the policy mode to prevent-learn, either for a specific ingress rule or for the whole policy.

Kong Gateway: Add protection to existing Ingress resource

open-appsec will secure traffic integrating directly with the Kong Gateway container, as this allows open-appsec to also inspect HTTPS traffic terminated at the Kong Gateway.

In order for traffic to reach your API Gateway you can use the Kong Controller as an Ingress Controller alongside Kong API Gateway (Kong Controller will be deployed by default within the same pod as Kong Gateway as an additional container, but is an optional component). Alternatively you can use another ingress controller of your choice.

If you use today an Ingress for proxying traffic to your Kong Gateway, you can easily update your existing K8S ingress resource to secure it's traffic with open-appsec. Once you apply the change, the ingress will reload and traffic will be protected.

Note: Having an Ingress Resource defined for traffic to Kong Gateway is mandatory for being able to protect the traffic with open-appsec, as the open-appsec policy resource has to be linked to an ingress resource via an annotation, see below steps. Additional options will be provided in the future.

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:

kubectl get policies.openappsec.io open-appsec-best-practice-policy -o yaml

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

For v1beta1 CRDs: Configuration Using CRDs

For v1beta2 CRDs: Configuration Using CRDs - v1beta2

b. Find out the name of your relevant ingress resource:

kubectl get ing -A

c. Edit the ingress resource:

kubectl edit ing/<ingress name> -n <ingress namespace>

d. Change the ingressClassname to use open-appsec:

spec: ingressClassName: appsec-kong

Make sure to use the correct name for the open-appsec policy resource which you created above.

e. Add this annotation to activate open-appsec:

openappsec.io/policy: open-appsec-best-practice-policy

The default mode of this policy is detect-learn. It will not block any traffic, unless you change the policy mode to prevent-learn, either for a specific ingress rule or for the whole policy.

APISIX Gateway: Add protection to existing Ingress resource

open-appsec will secure traffic integrating directly with the APISIX Gateway container, as this allows open-appsec to also inspect HTTPS traffic terminated at the APISIX Gateway.

In order for traffic to reach your API Gateway you can use the APISIX Ingress Controller as an Ingress Controller alongside APISIX API Gateway.

If you use today an Ingress for proxying traffic to your APISIX Gateway, you can easily update your existing K8S ingress resource to secure it's traffic with open-appsec. Once you apply the change, the ingress will reload and traffic will be protected.

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:

kubectl get policies.openappsec.io open-appsec-best-practice-policy -o yaml

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

For v1beta1 CRDs: Configuration Using CRDs

For v1beta2 CRDs: Configuration Using CRDs - v1beta2

b. Find out the name of your relevant ingress resource:

kubectl get ing -A

c. Edit the ingress resource:

kubectl edit ing/<ingress name> -n <ingress namespace>

d. Change the ingressClassname to use open-appsec:

spec: ingressClassName: appsec-apisix

e. Add this annotation to activate open-appsec:

openappsec.io/policy: open-appsec-best-practice-policy

Make sure to use the correct name for the open-appsec policy resource which you created above.

The default mode of the open-appsec-best-practice-policy is detect-learn. It will not block any traffic, unless you change the policy mode to prevent-learn, either for a specific ingress rule or for the whole policy.

Step 10: Validate that open-appsec works

Your existing or new Ingress is now running and you can try it out!

  1. Generate some traffic to one of the services defined in your ingress.

  2. Run this command to see logs:

Note the name of the ingress nginx pod by running:

kubectl get pods -n appsec

Show the logs of the open-appsec agent container by running:

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

Note the name of the Kong pod by running:

kubectl get pods -n appsec

Show the logs of the open-appsec agent container by running:

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

Note the name of the apisix gateway pod by running:

kubectl get pods -n appsec-apisix

Show the logs of the open-appsec agent container by running:

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

With the default policy logging being done to stdout, so you can easily direct it with fluentd/fluentbit or similar to logs collector (ELK or other). It is possible to configure open-appsec to log also to syslog.

open-appsec automatically logs the first 10 HTTP requests and then by default will only log malicious requests. You can change this setting.

Step 10: Point your DNS to the New Ingress

After testing that your services are reachable, you can point your public DNS record to the new ingress.

In case of a problem, at any time, you can either switch open-appsec off while running the same ingress code, or change your DNS back.

For Production usage you might want to switch from using the Basic to the more accurate Advanced Machine Learning model, as described here:

Using the Advanced Machine Learning Model

--set appsec.agentToken: set the deployment profile token from central management WebUI (SaaS) to connect your open-appsec deployment to the central WebUI (SaaS), also make sure to set appsec.mode to managed when you provide the token, see here how to get the token: .

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

--set appsec.agentToken: set the deployment profile token from central management WebUI (SaaS) to connect your open-appsec deployment to the central WebUI (SaaS), also make sure to set appsec.mode to managed when you provide the token, see here how to get the token: .

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

--set appsec.agentToken: set the deployment profile token from central management WebUI (SaaS) to connect your open-appsec deployment to the central WebUI (SaaS), also make sure to set appsec.mode to managed when you provide the token, see here how to get the token: .

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

RBAC
Helm 3 Package Manager
here
https://my.openappsec.io
Sign-Up and Login to Portal
Create a Profile
create a profile in web UI
here
create a profile in web UI
here
create a profile in web UI
here