How to protect Apps and APIs in Kubernetes from zero day attacks?
Tags: kubernetes, devops, cybersecurity, waf
Published: 2022-12-01 21:45:16

Written by: Eze Onukwube

A zero-day attack is a cybersecurity incident that occurs when a hacker exploits a vulnerability before anyone else, including key stakeholders like the product vendor or developers, realize anything is wrong.

To counteract these attacks, you can use [open-appsec](https://www.openappsec.io), a fully automated, open-source web application firewall (WAF). As a cutting-edge cybersecurity tool, open-appsec prevents zero-day attacks through its preemptive web app and API protection that leverages the dynamism of continuous machine learning (ML). However, its ML-based engine isn't a signature-based solution. 

This differentiates open-appsec from most security products on the market, especially antivirus, intrusion detection systems (IDS) and existing WAF solutions that rely on discerning threat signatures to detect malware and malicious code. As a result, open-appsec is ideal for remediating pen test results and protecting against zero-day and other [Open Web Application Security Project (OWASP) Top 10](https://owasp.org/www-project-top-ten/) attacks such as broken access control, data integrity failures, authentication failures, and code injections. 

In this article, you’ll learn about zero-day attacks and how to set up and use open-appsec to secure your web application. 
 
### open-appsec and ML 

The key to open-appsec's ability to prevent zero-day attacks lies with its contextual ML engine. 
It uses two machine ML models:
+ A supervised learning model that was trained offline based on millions of requests, both malicious and benign.
+ An unsupervised model to train itself in real time on incoming HTTP/S requests. This allows it to establish a baseline of what constitutes normal or benign traffic for a specific web application or API.

In order to enable an ML engine to quickly learn how an application is used, it should be allowed to run in [learn/detect mode](https://www.forbes.com/sites/forbestechcouncil/2017/05/02/how-does-a-machine-learn/?sh=5d951a1e7441) for two to three days. This typically provides ample time for the ML engine to train itself on a substantial amount of diverse traffic for better prediction accuracy.   

As a result, open-appsec is able to detect suspicious patterns and anomalous behavior that is not in line with the web application or API's conventional traffic, unlike most WAFs that are typically rule-based. This equips the ML engine to detect zero-day attacks without having any prior knowledge of the attack vector, threat signature, or payload used. In addition, a security administrator can apply tuning suggestions to the ML engine to improve targeted accuracy. 

## Agents and Other Key Concepts of open-appsec 

In this tutorial, you'll use agents to implement open-appsec. But before you begin this tutorial, let's talk a bit more about what an open-appsec agent is and what it does.

### What Is an open-appsec Agent?

Agents are the primary means of deployment in open-appsec. They're ideal for any infrastructure due to their light digital footprint, minimal latency, and the fact that they don't alter the existing infrastructure.

The first step in implementing open-appsec for your application is deciding the type of agent deployment you want to use. In order to make an informed decision, it's imperative to understand how agents and their different deployment types work in open-appsec.

While agents are designed as standalone components, open-appsec also gives you the option to connect them to the software as a service (SaaS) management portal (more on this in the following sections). 

Agents are generally deployed on any computing endpoint where client requests are received or routed such as a web server, reverse proxy, or Kubernetes Ingress. Because of this, the agent is best poised to detect and prevent malicious threats since the open-appsec core ML engine is designed to process incoming HTTP/S requests. 

Agents are empowered to act as standalone entities since their security processing is done locally. However, they can be managed by a master SaaS component called a [Fog](https://docs.openappsec.io/concepts/agents). The Fog is responsible for logging in addition to configuration and software updates necessary for ML learning data synchronization between agents. 

To further bolster security, agents communicate with the Fog only through encrypted and authenticated channels. When the Fog is unreachable for one reason or another, the agent is still capable of security enforcement. However, some administrative functions will be unavailable when the Fog is unattainable. 

open-appsec aims for flexibility and it provides three agent deployment types: container, NGINX addon, and Kubernetes Ingress Controller. 

### Deploying an Agent Stand-Alone vs. Connected to the SaaS Management Portal

After you've deployed an open-appsec agent, you have the option of managing the deployment with the SaaS Central Management web user interface. If you choose to use SaaS Central Management, its portal allows you to centrally manage your open-appsec deployment with more flexibility and comfort.

However, there is a significant difference between deploying a standalone agent and deploying one connected to the SaaS management portal. While the former is adequate for implementing open-appsec security, the latter offers more to users with its multilayered functionality that provides granular control and oversight of several agent deployments. 

With the SaaS management portal, you can edit your web application/API security settings from the convenience of a user-friendly web UI. In addition to policy editing, its web interface provides advanced situational awareness tools. This is a huge benefit, especially when you are managing large deployments:

![A diagram showing the SaaS management portal](https://i.imgur.com/y3IxDq0.png)

As you can see, it provides three major hubs, namely: **Protection**, **Central Management**, and **Situational Visibility**. While deploying standalone open-appsec for Kubernetes Ingress provides effective protection, you have more opportunities and options when you connect to the management portal.

## Implementing open-appsec for Your API or Web Application 

The fastest way to set up open-appsec for K8s is through the interactive Kubernetes CLI tool. One of the best things about this tool is that it's easy to use, and guides you through most of the common customizations needed. 

However, a certain amount of Kubernetes knowledge and system resources are needed before you can successfully install and run this interactive tool. According to [open-appsec's documentation](https://docs.openappsec.io/getting-started/start-with-kubernetes/install-using-interactive-cli-tool), the following are the prerequisites required to use the Kubernetes CLI tool:


* An understanding of Kubernetes Ingress, in addition to knowing how to configure it or having previously deployed Ingress.
* A Kubernetes 1.16.0+ cluster with role-based access control (RBAC) enabled cluster admin permissions.
* Access to command line tools such as [wget](https://www.gnu.org/software/wget/) and [kubectl](https://kubernetes.io/docs/reference/kubectl/) on either a bastion host or a cloud platform that provides you with a Kubernetes cluster. 
* [Helm 3](https://helm.sh/blog/helm-3-released/), the Kubernetes package manager, installed on your local machine. 

You can also peruse the [open-appsec source code and information in this GitHub repo](https://github.com/openappsec/) to gain more insight into the nuts and bolts of the system.

### Deploying an Agent to Your Application

To download and run the open-appsec installer, you can set up open-appsec either in the [Killercoda Playground](https://killercoda.com/playgrounds) (which is what you'll use her) or on your own Kubernetes cluster.

> Please note: The information given and explained in this section (and subsequent ones) can be found in the [official open-appsec documentation](https://docs.openappsec.io/getting-started/start-with-kubernetes/install-using-interactive-cli-tool).

### Setting Up open-appsec to Use the Kubernetes CLI Tool

[Killercoda's Playground](https://killercoda.com/) provides interactive environments. As its name implies, these playground environments can be used risk-free for quick and easy deployment and first hands-on experience with modern solutions like open-appsec in immediately available, ready-to-use environments. 

You can launch open-appsec's Playground by navigating to [Killercoda's website](https://killercoda.com/open-appsec/scenario/simple-appsec-kubernetes-ingress) or by clicking on the Playground menu item on the SaaS portal:

![The Playground menu option on the SaaS management portal ](https://i.imgur.com/7UCR0jF.png)

If you haven't logged in, or if you don't have an open-appsec Playground account, you'll see an interface with various options to sign in or create an account, using either GitLab, GitHub, Google, or email:

![Playground along with a signup/login form ](https://i.imgur.com/ae4cUQb.png)

The Playground provides you with a free, computing environment through a terminal in your browser. After you've successfully logged in and the Playground has finished initializing, you’ll see a terminal interface similar to this:

![An authenticated Playground interface fully initialized](https://i.imgur.com/0Igr5Jp.png)

To begin using open-appsec, you need to download the install script and adjust its permissions: 

```
wget https://downloads.openappsec.io/open-appsec-k8s-install && chmod +x open-appsec-k8s-install
```

If you're using the Playground, all you need to do is click on the link following **Download open-appsec install script** to activate the download:

![A completed execution of the open-appsec download script](https://i.imgur.com/BWMWpiz.png)

Then, run the downloaded install script:

```
./open-appsec-k8s-install
```

If you're using the interactive Playground, you'll notice the script is run as `./open-appsec-k8s-install --prevent`. However, in a live environment, you don't want to add the `--prevent` attribute since you'll want to start open-appsec in its learn-detect mode. This allows its ML engine to learn the traffic patterns of your application. 

Once the install script has been successfully executed (it may take some time), you should see a message similar to this on the command line: 

```
open-appsec for Kubernetes Ingress Installer v1.2232.1
```

> Most likely, you'll see a variation of the current Kubernetes version that open-appsec is using. 

After the Kubernetes installer version is displayed, a subsequent line will give you a heads-up and preview of what the installer will be doing next:

![Image of Installer information on generating manifest and Helm charts](https://i.imgur.com/TrpSxay.png)

Below is a panoramic view of Playground after running the install script:

![A successful execution of the open-appsec installation](https://i.imgur.com/2ZUgJYc.png)

### Adding the open-appsec Agent to Kubernetes Ingress

After downloading and running the installer, the next step involves adding open-appsec to either a duplicate of an existing Ingress or directly to an existing Ingress.

Immediately after the successful installation of open-appsec, the installer displays a table of the existing ingresses, detailing information pertaining to it:

![Image of existing Ingress with headings](https://i.imgur.com/fwsk8ic.png)

As shown in a prior image depicting its successful installation, Playground then provides you with two options to apply to the existing Ingress:

1. Duplicate an existing Ingress and add open-appsec to it. 
2. Add open-appsec to an existing Ingress resource.

The first option allows the existing Ingress to operate without disruption to traffic while you add open-appsec and conduct tests on the newly created Ingress. The second option merely adds open-appsec to the existing Ingress. Due to the risk of disruption, the second option is suited for testing purposes or use in a non-critical production environment.

Select the option that corresponds to your situation and you'll be prompted to enter both the name and namespace of the existing or duplicate Ingress.

The next step gives you the opportunity to change the Ingress' policy. The CLI displays the default policy rules of the current Ingress:

![Image display the default rules of the current Ingress](https://i.imgur.com/G60rrYW.png)

You have the option of using the default Ingress policy as it is or selecting other options. As you can see from the image below, some of the options presented include changing a rule, adding a rule, deleting a rule, or saving the current policy:

![Saving and/or changing the default policy](https://i.imgur.com/Rtol04L.png)

For instance, if you decide to change the rule of the default policy, and select option 1 (`Change Rule` in the previous screenshot), you’ll be asked to make further choices. You can choose to set a new name, namespace, Ingress rule, protection level, mode, or web response:

![Image for change rule options for the default policy](https://i.imgur.com/AwrZsGr.png)

The final step of adding the open-appsec agent to Kubernetes Ingress applies the configuration options you selected in the previous two steps to either a manifest (YAML file) or a Helm chart. Finally, save your current policy by selecting one of those options:

![Apply configuration options to the Kubernetes Ingress ](https://i.imgur.com/aP5hREK.png)

When executed, the installer will apply your configuration to one of these three files:

- The **`ingress.yaml`** file, which is the manifest created based on your instructions in the first step.
- The **`open-appsec-policy.yaml`** file, which is created based on your selections in the second step.
- The **open-appsec Helm chart**, which includes CRDs and other necessary files.

Because you selected to save your current policy, your setup should be saved to the `open-appsec-policy.yaml` file:

![Image of setup saved to open-appsec-policy.yaml](https://i.imgur.com/NLafR5i.png)

> You may see something different depending on the prior options you chose.

Playground will then notify you it's time for the final configuration step. This is initiated when you execute the `Run now` option:

![Image for running the commands to apply the configuration](https://i.imgur.com/m6w0zoq.png)

After you execute the run command, you will see the installation steps being executed (for open-appsec Helm chart, Ingress resource and the open-appsec policy custom resource):

![Complete installation of open-appsec](https://i.imgur.com/NyIIvrx.png)

## Connect Your Deployment to the SaaS Web-Based Management

As its name suggests, the SaaS web-based management portal provides the convenience of a graphical UI interface along with sophisticated functionality to oversee, optimize, and control the security configuration of open-appsec deployed agents. You can also analyze all security logs in a flexible way. Before you can connect the deployed open-appsec agent to the SaaS web-based management portal, you'll be required to first create an account on it. 

### Creating an Account on the open-appsec Portal

To reach the open-appsec portal's main page, navigate to [https://my.openappsec.io](https://my.openappsec.io).


You should see a web form that asks you to create an open-appsec account using your Google, GitHub, or email account. Once you provide your credentials and are authenticated, you will be taken to the **Getting Started** page.

After you create and deploy an agent to protect a website or app, you have the option of connecting it to SaaS web-based management.

The SaaS-based management provides central policy editing using a web interface and other advanced situational awareness tools. These are huge benefits when managing large deployments. 

Once you’ve logged in successfully, you'll be redirected to the home page. Once there, you need to confirm your agent has been deployed. Under the **Protection** box, check "I deployed an agent" which will enable the **Central Management** box:

![Image acknowledging agents have been deployed to SaaS](https://i.imgur.com/RbMqfsK.png)

Then, under **Central Management**, select **Manage**, and from the dropdown menu, select **Kubernetes Profile**:

![Central management drop-down with profile options](https://i.imgur.com/smyGO1Q.png)

This creates a Kubernetes profile that represents and controls the agents deployed in your cluster:

![Download and deployment form to copy code for creating a profile](https://i.imgur.com/75bPz9Z.png)

In order to create secure communication between your agent and the SaaS management, you need to connect to the SaaS application. Onscreen instructions might advise you to enforce the policy if you haven’t already done so:

![Enforce the Kubernetes policy](https://i.imgur.com/QBZznu0.png)

Under **Downloads & Deployment**, you'll also see a message reiterating the need to enforce the policy (if you haven’t already done so).  After this message, copy the commmand required to connect to your deployment from the **Connect your deployment** box, which contains the open-appsec token. This token connects your agents deployment to the newly created profile and creates a secure communication channel between the open-appsec deployment and the cloud:

![Copy code to connect your deployment](https://i.imgur.com/1ublk4h.png)

Paste the command into the Kubernetes console, which could be Playground or your own Kubernetes setup. After it executes, your deployment can now be centrally managed in the SaaS portal.

## Monitoring Cybersecurity Events after You Simulate an Attack 

The best way to understand how open-appsec's event monitoring works is to simulate a cyber attack. This enables you to see how it chronicles threat protection and other relevant sequences of actions.

Fortunately, you don't have to come up with a cybersecurity incident on your own. Through the Playground, you can access open-appsec's **Acme Audit** application to simulate a SQL injection attack:

![Acme audit application](https://i.imgur.com/mmH7p6f.png)

### Validating open-appsec Protection and Events Monitoring After Attack Simulation

In open-appsec, event monitoring is done through the SaaS management portal. You need to have previously configured it with a deployed open-appsec agent protecting the website or the application. This is why, in the previous section, you used the Playground interactive environment to simulate an attack on the **Acme Audit** application. 

As you can see from the following image, the SQL injection attack attack on the **Acme Audit** app failed, HTTP error 403 is shown indicating that open-appsec successfully prevented the threat:

![open-appsec’s Playground showing successful prevention of a SQL injection cyberattack](https://i.imgur.com/cf5qbDb.png)

This signals that the Kubernetes Ingress and its services were protected. However, it's also beneficial to see how the threat protection worked by viewing the actions and events generated by the attack. 

To do this, log in to the SaaS portal and select **Monitoring** and the **All Events** tab. This will display the relevant actions triggered by the attack and its threat prevention:
 
![Threat events captured during a 7-day time span](https://i.imgur.com/Sy7KZCr.png)

As you can see, a table is displayed with rows containing all the events that occurred within a certain time range. It includes the timestamps of the individual events, along with their level of severity, source IP address, and several other details. 

You can see that there was a critical severity event that occurred precisely on Oct 4, 2022, at 4:49:33 PM. It reports that the incident type was a SQL injection attack that was prevented. 

When you scroll horizontally to the right across the table, you'll find other granular details that help you better understand the nature of the threat and attack vector used. For instance, the text command used for the SQL injection attack is revealed under the **Matched String** field, while **HTTP URI Path** shows the exploit was carried out during a login procedure:

![Critical threat events](https://i.imgur.com/4c1lmpy.png)

Alternatively, you can select the **Important Events** tabs to display only those security events with critical and high severity. To target event types more narrowly, filters are activated by checking the box options you want to view:

![Important events tab](https://i.imgur.com/u7v0xNC.png)

Additionally, the portal provides you with a panoramic and graphical appsec dashboard through which you can access various sections with important security sections. These sections include security actions, overall HTTP traffic, malicious activity, attack levels, and top attacked assets. You can drill down for more information by clicking on individual sections. 

![open-appsec dashboard](https://i.imgur.com/As9xhcb.png)

## Conclusion
ML-based threat prevention is the best and most practical defense against zero-day attacks. In this article you learned how to configure and deploy an [open-appsec](https://www.openappsec.io) in Kubernetes. You also learned how to leverage open-appsec’s SaaS management portal as an effective agent monitoring dashboard to provide centralized logging, events analysis, and handling of multiple deployments in a scalable manner.