Responsive

Security Testing in Kubernetes with OWASP ZAP and Testkube

Jun 9, 2023
4min
read
Alejandra Thomas
Developer Advocate
Testkube
Ensure the security of your Kubernetes deployments with Testkube's newest integration, OWASP ZAP.
Share on Twitter
Share on LinkedIn
Share on Reddit
Share on HackerNews
Copy URL

Table of Contents

Want to learn more about this topic? Check out our Office Hours sessions!

Get Started with Testkube Pro

In today’s software development landscape, ensuring the security of your applications is one of the most important, yet often overlooked tasks. With the increasing adoption of containerization and Kubernetes for app deployment, it becomes crucial to strengthen your applications against vulnerabilities and attacks. One effective tool that can aid in this endeavor is [OWASP Zed Attack Proxy (ZAP)](http://testkube.io/integration/zap-testkube-integration). In this blog post, we will explore how and why you should incorporate [security testing with OWASP ZAP into your Kubernetes applications](https://testkube.io/blog/security-testing-in-kubernetes).

## Why should you perform security testing in Kubernetes?

Before delving into the specifics, let's briefly discuss why security testing is indispensable for your applications. The primary goal of security testing is to identify and mitigate potential vulnerabilities and weaknesses that may exist within your app's infrastructure, code, or configurations. By conducting regular security testing, you can proactively identify and address vulnerabilities, reducing the risk of exploitation and data breaches.

## What is OWASP ZAP?

OWASP ZAP, a widely adopted open-source security testing tool, provides a comprehensive suite of features for detecting and mitigating security risks within web applications. It offers powerful capabilities to scan, test, and identify vulnerabilities across various layers, including the application's front end, back end, and APIs. ZAP's active and passive scanning techniques, combined with its user-friendly interface, make it a popular choice for developers, security testers, and penetration testers.

So now that we know how these pieces come together, let’s take a look at how we can bring our ZAP tests into our Kubernetes environment. For this, we’ll use Testkube.

## What is Testkube?

If you’re new around here, Testkube is a test execution and orchestration framework for Kubernetes that works with any CI/CD system and testing tool you need, empowering teams to deliver on the promise of agile, efficient, and comprehensive testing programs by leveraging all the capabilities of Kubernetes to eliminate CI/CD bottlenecks, perfecting your testing workflow.

If you haven’t used Testkube yet, [get started today](http://cloud.testkube.io) to start testing your applications in Kubernetes. 

Let’s start by [signing into Testkube](http://cloud.testkube.io) to perform our first ZAP test.

## Running a Zed Attack Proxy test in Kubernetes

With [native support for ZAP tests](https://docs.testkube.io/test-types/executor-zap), all you need to do to run tests within Testkube is populate a file with the necessary parameters when creating your test.

The official [ZAP Docker image](https://www.zaproxy.org/docs/docker/), on which the executor was built, lets you run three types of tests: **baseline**, **full** and **API scans**. Depending on which of these functionalities you want to leverage, the test creation looks slightly different. Not only the type of the test (`--type`) needs to be specified differently, but the configuration file will also have some parameters that do not work with all types.

To look at the different types of tests and their respective parameters, refer to our [documentation](https://docs.testkube.io/test-types/executor-zap).

In this tutorial, we’ll run an API scan, which will be tuned to perform scans against APIs defined by OpenAPI, SOAP, or GraphQL via a local file.

 For this, we’ll upload our definition file that’s stored locally into Testkube. The content for this file will look like this:

```yaml
api:
  # -t the target API definition
  target: https://www.example.com/openapi.json
  # -f the API format, openapi, soap, or graphql
  format: openapi
  # -O the hostname to override in the (remote) OpenAPI spec
  hostname: https://www.example.com
  # -S safe mode this will skip the active scan and perform a baseline scan
  safe: true
  # -c config file
  config: /data/uploads/zap-tk-api.conf
  # -d show debug messages
  debug: true
  # -s short output
  short: false
  # -l minimum level to show: PASS, IGNORE, INFO, WARN or FAIL
  level: INFO
  # -n context file
  # context: /data/uploads/context.conf
  # username to use for authenticated scans
  user: anonymous
  # delay in seconds to wait for passive scanning
  delay: 5
  # max time in minutes to wait for ZAP to start and the passive scan to run
  time: 60
  # ZAP command line options
  zap_options: -config aaa=bbb
  # -I should ZAP fail on warnings
  fail_on_warn: false
```

ZAP will import the definitions that we specified in our file through Testkube and then run an Active Scan against the URLs scanned. 

To run a different type of ZAP test, change the first line to either `baseline`, `full`, or like in our case, `api`, and refer to the [ZAP documentation](https://www.zaproxy.org/docs/docker) to see how to define each type of test.

Now, let’s create our test with the following command:

```bash
testkube create test --git-uri https://github.com/kubeshop/testkube.git --type "zap/api" --name git-zap-api-test --executor-args "zap-api.yaml" --git-branch main --git-path contrib/executor/zap/examples
```

To run it, simply type in the following:
```bash

kubectl testkube run test --watch git-zap-api-test
```

Note: Ideally, for tests running in production, you would use a Git repository to keep track of the changes the test went through. When running these tests, Testkube will clone the repository every time. An example test creation command would look something like this:

```bash

$ testkube create test --git-uri https://github.com/kubeshop/testkube.git --type "zap/api" --name git-zap-api-test --executor-args "zap-api.yaml" --git-branch main --git-path contrib/executor/zap/examples

```

Since we added the –watch flag, we’ll be able to immediately follow our execution and logs live. To print the results after our execution is done, simply type in:

```bash

testkube get execution zap-api-test-1

```

## Get Started with ZAP Security Testing

That’s it! You’re now on your way to running security tests in Kubernetes with ZAP and Testkube. ZAP can be used in multiple ways to secure your applications – by actively scanning the communication protocols and detecting vulnerabilities that could be exploited; or by passively scanning traffic to identify potential security threats, making it a crucial tool in the continuous monitoring of security in a cloud-native landscape. When you add Testkube to the security equation, you can seamlessly integrate into your existing workflow, automate the security testing to ensure security over your deployments, and allow security checks into your CI/CD deployment pipelines. 

Hope this helps you to [get started with security testing](http://cloud.testkube.io/) in Kubernetes. If you get stuck or have questions, we’re here to help! Find an answer to your questions in the [Testkube Knowledge Base](https://testkube.io/knowledge-base) or [reach out to us on Slack](https://bit.ly/testkube-slack). We’re eager to hear how you use our new ZAP integration.

Alejandra Thomas
Developer Advocate
Testkube
Share on Twitter
Share on LinkedIn
Share on Reddit
Share on HackerNews
Copy URL
Responsive

Security Testing in Kubernetes with OWASP ZAP and Testkube

Jun 9, 2023
4min
read
Ensure the security of your Kubernetes deployments with Testkube's newest integration, OWASP ZAP.
Share on Twitter
Share on LinkedIn
Share on Reddit
Share on HackerNews
Copy URL

Table of Contents

Want to learn more about this topic? Check out our Office Hours sessions!

Get Started with Testkube Pro

In today’s software development landscape, ensuring the security of your applications is one of the most important, yet often overlooked tasks. With the increasing adoption of containerization and Kubernetes for app deployment, it becomes crucial to strengthen your applications against vulnerabilities and attacks. One effective tool that can aid in this endeavor is [OWASP Zed Attack Proxy (ZAP)](http://testkube.io/integration/zap-testkube-integration). In this blog post, we will explore how and why you should incorporate [security testing with OWASP ZAP into your Kubernetes applications](https://testkube.io/blog/security-testing-in-kubernetes).

## Why should you perform security testing in Kubernetes?

Before delving into the specifics, let's briefly discuss why security testing is indispensable for your applications. The primary goal of security testing is to identify and mitigate potential vulnerabilities and weaknesses that may exist within your app's infrastructure, code, or configurations. By conducting regular security testing, you can proactively identify and address vulnerabilities, reducing the risk of exploitation and data breaches.

## What is OWASP ZAP?

OWASP ZAP, a widely adopted open-source security testing tool, provides a comprehensive suite of features for detecting and mitigating security risks within web applications. It offers powerful capabilities to scan, test, and identify vulnerabilities across various layers, including the application's front end, back end, and APIs. ZAP's active and passive scanning techniques, combined with its user-friendly interface, make it a popular choice for developers, security testers, and penetration testers.

So now that we know how these pieces come together, let’s take a look at how we can bring our ZAP tests into our Kubernetes environment. For this, we’ll use Testkube.

## What is Testkube?

If you’re new around here, Testkube is a test execution and orchestration framework for Kubernetes that works with any CI/CD system and testing tool you need, empowering teams to deliver on the promise of agile, efficient, and comprehensive testing programs by leveraging all the capabilities of Kubernetes to eliminate CI/CD bottlenecks, perfecting your testing workflow.

If you haven’t used Testkube yet, [get started today](http://cloud.testkube.io) to start testing your applications in Kubernetes. 

Let’s start by [signing into Testkube](http://cloud.testkube.io) to perform our first ZAP test.

## Running a Zed Attack Proxy test in Kubernetes

With [native support for ZAP tests](https://docs.testkube.io/test-types/executor-zap), all you need to do to run tests within Testkube is populate a file with the necessary parameters when creating your test.

The official [ZAP Docker image](https://www.zaproxy.org/docs/docker/), on which the executor was built, lets you run three types of tests: **baseline**, **full** and **API scans**. Depending on which of these functionalities you want to leverage, the test creation looks slightly different. Not only the type of the test (`--type`) needs to be specified differently, but the configuration file will also have some parameters that do not work with all types.

To look at the different types of tests and their respective parameters, refer to our [documentation](https://docs.testkube.io/test-types/executor-zap).

In this tutorial, we’ll run an API scan, which will be tuned to perform scans against APIs defined by OpenAPI, SOAP, or GraphQL via a local file.

 For this, we’ll upload our definition file that’s stored locally into Testkube. The content for this file will look like this:

```yaml
api:
  # -t the target API definition
  target: https://www.example.com/openapi.json
  # -f the API format, openapi, soap, or graphql
  format: openapi
  # -O the hostname to override in the (remote) OpenAPI spec
  hostname: https://www.example.com
  # -S safe mode this will skip the active scan and perform a baseline scan
  safe: true
  # -c config file
  config: /data/uploads/zap-tk-api.conf
  # -d show debug messages
  debug: true
  # -s short output
  short: false
  # -l minimum level to show: PASS, IGNORE, INFO, WARN or FAIL
  level: INFO
  # -n context file
  # context: /data/uploads/context.conf
  # username to use for authenticated scans
  user: anonymous
  # delay in seconds to wait for passive scanning
  delay: 5
  # max time in minutes to wait for ZAP to start and the passive scan to run
  time: 60
  # ZAP command line options
  zap_options: -config aaa=bbb
  # -I should ZAP fail on warnings
  fail_on_warn: false
```

ZAP will import the definitions that we specified in our file through Testkube and then run an Active Scan against the URLs scanned. 

To run a different type of ZAP test, change the first line to either `baseline`, `full`, or like in our case, `api`, and refer to the [ZAP documentation](https://www.zaproxy.org/docs/docker) to see how to define each type of test.

Now, let’s create our test with the following command:

```bash
testkube create test --git-uri https://github.com/kubeshop/testkube.git --type "zap/api" --name git-zap-api-test --executor-args "zap-api.yaml" --git-branch main --git-path contrib/executor/zap/examples
```

To run it, simply type in the following:
```bash

kubectl testkube run test --watch git-zap-api-test
```

Note: Ideally, for tests running in production, you would use a Git repository to keep track of the changes the test went through. When running these tests, Testkube will clone the repository every time. An example test creation command would look something like this:

```bash

$ testkube create test --git-uri https://github.com/kubeshop/testkube.git --type "zap/api" --name git-zap-api-test --executor-args "zap-api.yaml" --git-branch main --git-path contrib/executor/zap/examples

```

Since we added the –watch flag, we’ll be able to immediately follow our execution and logs live. To print the results after our execution is done, simply type in:

```bash

testkube get execution zap-api-test-1

```

## Get Started with ZAP Security Testing

That’s it! You’re now on your way to running security tests in Kubernetes with ZAP and Testkube. ZAP can be used in multiple ways to secure your applications – by actively scanning the communication protocols and detecting vulnerabilities that could be exploited; or by passively scanning traffic to identify potential security threats, making it a crucial tool in the continuous monitoring of security in a cloud-native landscape. When you add Testkube to the security equation, you can seamlessly integrate into your existing workflow, automate the security testing to ensure security over your deployments, and allow security checks into your CI/CD deployment pipelines. 

Hope this helps you to [get started with security testing](http://cloud.testkube.io/) in Kubernetes. If you get stuck or have questions, we’re here to help! Find an answer to your questions in the [Testkube Knowledge Base](https://testkube.io/knowledge-base) or [reach out to us on Slack](https://bit.ly/testkube-slack). We’re eager to hear how you use our new ZAP integration.