Using Wiremock for Fun and Mocking

Reading Time: 3 minutes

Mocking – something we all need, and yet, usually, hate. Simply because writing mocks is a boring and cumbersome task. The good news – it doesn’t have to be like that. There are so many good alternatives that make mocking easier: From libraries that ease the process of writing the mock, though contract testing with Pact (which solve the problem in a totally different way) to automatically generating mocks using Swagger/Open API spec. All are really good solutions – but today I want to focus on WireMock: A tool that really makes mocking a fun.

Why WireMock?

WireMock is a mocking tool (like the name implied). It can be used programmatically to create a mock, but the interesting part is the interactive mode. In the interactive mode, you first use WireMock to record requests to the real API (by proxying the requests and responses). Once the recording completed, WireMock produces mocking from the proxied requests and responses. Using the interactive mode eliminate all the hard work of writing a mock and let you focus on your actual tests. Because the mocks are based on the recording of the actual traffic, the mock is identical to the original API, which makes the tests more reliable. And lastly – updating the mock is as simple as re-recording the requests/responses. Let’s take a look at a real example (or just take a look at Kamus end-to-end tests).

Mocking Kubernetes API

While working on Kamus (a secret encryption/decryption for Kubernetes), I had to mock Kubernetes API. Let’s see what how easy it is using WireMock!
After downloading and running WireMock (java -jar java -jar wiremock-standalone-2.18.0.jar), open http://localhost:8080/__admin/recorder/ in your browser:

WireMock recorder UI
Clean and simple UI

Fill the details of the target API (in my case, it is the local Kubernetes proxy URL – http://localhost:8001), and hit “Record”. Now, all we need to do is point our code to http://localhost:8080 instead of Kubernetes API, and run it. Now it’s time to play with our API – make sure to call every functionality so WireMock call record all the different requests and responses (and yes, this should include error cases). This is very similar to how you explorer an application with Zaproxy, just for different purposes…

After the code run completed, hit “Stop” in WireMock UI. Now if you’ll look at the folder when you run WireMock, you’ll notice a new folder there with the name “mapping”. This folder contains all the requests and responses recorded (see an example here).

Putting it all together

Now that we have the recording ready, all that is left is running the tests. To run the tests, I use docker-compose. This how the docker-compose.yaml look like in Kamus:

version: '3'
      - Kubernetes__ProxyUrl=http://wiremock:8080
      context: ../
     - ENCRYPTOR=http://encryptor:9999/
     - DECRYPTOR=http://decryptor:9999/
     - PROXY_URL=http://zap:8090
     - KUBERNETES_URL=http://wiremock:8080
     - ./reports:/reports

      context: ../Wiremock

I defined 4 services – Kamus API (encryptor and decryptor), tests, and WireMock. Notice the KUBERNETES_URL  environment variable – see how it points to Wiremock. Running WireMock in docker is really simple – this is the docker file:

FROM openjdk:8-stretch

WORKDIR /wiremock

RUN wget

COPY . .

CMD ["java", "-jar", "wiremock-standalone-2.17.0.jar"]

Notice the copy instruction – this where I copy the mapping folder.
Now that we have all set – all we need to do in order to run the tests is a simple docker compose command (take a look at Kamus CI if you don’t believe me):

docker-compose up --build --exit-code-from black-box.

The tests will run, and the code will use WireMock instead of Kubernetes API.


Isn’t mocking with WireMock fun?

Threat Modeling as Code

Reading Time: 6 minutes

Infrastructure-as-code (and GitOps) extend the use of source control (git) and code (well, manifest files) into a new field. This changed radically how we create infrastructure in the cloud, by making the process more robust and less error prone, and also easier for developers. Can we do the same for threat modeling? How can threat-modeling-as-code change and improve the way we do threat modeling today?

Let’s start with a really short introduction to threat modeling. Threat modeling is a practice that help us take a system design and look for possible security issues, by asking these 4 questions:

  1. What are we building?
  2. What can go wrong?
  3. What are we doing about it?
  4. Are we doing a good job?

Conduction a threat model helps to find issues sooner – and in most cases, detect issues that are hard to find using other practices. This is why conducting a threat model is a critical part in building a secre software. If you’re not familiar with this practice, I’m highly recommending this post by Adam Shostack, one of the authorities in the field. OWASP Threat Modeling project (and channel) is also an excellent learning resource.

Continue reading “Threat Modeling as Code”

What’s inside the box?

Reading Time: 4 minutes

In the last two weeks, I was working on releasing the first OSS release of Kamus, a secret management solution for Kubernetes. To release Kamus, I had to publish a few docker images to Docker Hub and the CLI – which is deployed as an NPM package. This was the first time I had to deal with deploying packages to a repository. Doing this process thought made me thinks a lot about the (in)security of this process, and I want to share these thoughts with you. It’s all sums up to one small question – what’s inside the box? Do you know what you install when you download a package from a repository?

Continue reading “What’s inside the box?”

Hacking Juice Shop, the DevSecOps Way

Reading Time: 6 minutes

Every DevSecOps engineer will recommend you to start using security tests. I personally just blogged about it recently – if you’re not familiar with the concept, I’ll highly encourage you to read it first. It’s sound right, but there is one important question: Can we find real exploits using security tests? Can we pwn a web application by scanning it for security issues?

The best way to find out is to take a real broken web application, scan it with various security tests and look for exploits we can use. Today victim is OWASP Juice Shop, a very famous vulnerable web application, written using NodeJS and Angular. Let’s try to hack it, the DevSecOps way!

Continue reading “Hacking Juice Shop, the DevSecOps Way”

Investigating Kubernetes Nodes Disk Usage

Reading Time: 3 minutes

Today, I looked at our production Kubernetes cluster dashboard and I noticed something weird:

disk usage is high - almost 80%!
(sum (node_filesystem_size) – sum (node_filesystem_free)) / sum (node_filesystem_size) * 100

Well, this looks pretty bad. This is the average disk usage of the nodes running in the cluster. On average, only 20% percent of the disk in each node is available. This is probably not a good sign.

Continue reading “Investigating Kubernetes Nodes Disk Usage”

Leveraging Web Security to Harden WordPress Security

Reading Time: 6 minutes

As you might already notice, my new blog is powered by WordPress. When I chose to start a new blog and run it WordPress, I started to look on WordPress security. There are already great posts about improving the security of your WordPress site (see for example this and this guides). There are also many posts describing various security plugins you should be installing.

All this information is critical – but it’s not enough. What about elementary web security practices? For example, leveraging security headers to protect your site? Or enabling security.txt so good hackers will know how to contact you, in case they find a vulnerability in your site?

Continue reading “Leveraging Web Security to Harden WordPress Security”

Want to Write Good Code? Start Using Security Tests

Reading Time: 12 minutes

I like to write code. I’m doing it a lot, both professionally and for fun. Still, writing a good code is a challenge. Writing a code that is working, maintainable and secure is very hard to achieve. This is why we need automation – to spot the issues we missed. Tools like unit tests, code coverage or security tests can help detect various issues and help us write a better code.

Let’s take an example. I’ve created a small sample app using .NET core, my favorite language. I also created one container so we have something to play with.

Now it’s time to ask – does this code has security issues? Can I publish it to production?

You can try to answer this question by reading the code, or read along and learn what tools you can start using today to spot these issues. Continue reading “Want to Write Good Code? Start Using Security Tests”