- Use Case
- Log in →
- Introducing Cloudflare support for Home Assistant remote access
- Setting up simple, self-hosted & fast CI/CD solution with Drone.io
- Controlling TV with Google Home, IFTTT and Node-RED
- Node-RED OwnTracks location tracking without public IP/MQTT
- Secure webhooks to Jenkins on Kubernetes
- Remote YouTube downloader Slack bot
- Introducing WebSocket Server
- Rancher - push to deploy workflow with Keel
- Documenting your API with OpenAPI (Swagger) and Redoc
- Home Assistant remote access add-on
- Hassle-free remote access to Home Assistant on a Raspberry Pi
- How to receive Paypal webhooks on localhost
- DevOps Use Case: Performing Redis maintenance in Kubernetes
- Auto deploy your Node.js app on push to GitHub in 3 simple steps
- What is a webhook and how to create one?
- Mailgun webhook fan-out
- Web Relay Ingress with Docker for Mac
- How to receive Stripe webhooks on localhost
- Receive Github webhooks on Jenkins without public IP
- Keel - automated Kubernetes updates
Secure webhooks to Jenkins on Kubernetes
Dec 18, 2018, by Karolis Rusenas
Photo by Marat Gilyadzinov
There is no doubt that Jenkins is a great tool for both CI & CD. However, due to its access to your infrastructure, it becomes an easy target for attackers. For this reason Jenkins is often put behind a firewall and in doing so, webhooks stop working. Users do not want the pull-based but rather prefer the build to start as soon as there is a commit/tag/docker push!
Webhook Relay allows webhooks to start working again in a secure way, i.e. traffic is allowed to go only one way. Main advantages of using Webhook Relay:
- Security for your Jenkins instance by allowing only one-way traffic.
- Your Jenkins instance doesn’t have to be exposed to the internet. It can even be running on your local machine without configuring NAT/firewall.
- Auditability (webhook logs can be reviewed).
- Resend webhooks via Webhook Relay dashboard to make testing or adding new integrations easier.
Currently, there is no limitation on which Git (or anything else) can work with this approach so if you are using Github, Gitlab, you will be a perfect candidate. The only limitation at the moment is the webhook size - 3MB. However, this should be sufficient as standard Github webhooks are 8KB size.
- Webhook Relay account
- Kubernetes environment, we will be using Minikube
- Github account
- Some knowledge about Jenkins
You can use any Kubernetes environment, just one step might be different (getting Jenkins authentication token). Github can be exchanged for Gitlab, as Jenkins supports those webhooks too.
Our strategy is quite simple. At first, we create a secret with authentication details to Jenkins. We then deploy a Jenkins instance with Webhook Relay as a sidecar. Once it’s deployed, we sign in into Jenkins and create a freestyle project.
Go to your tokens page and create a token key & secret.
Once this is done, create a Kubernetes secret
This secret will be used by our Webhook Relay sidecar to authenticate to your account and receive your webhooks.
First, let’s create a Webhook Relay bucket to get our public endpoint:
- Go to https://my.webhookrelay.com/buckets
- Click on CREATE BUCKET in the top right corner
- Name bucket ‘jenkins’ and add sidecar configuration:
Since our agent will be running as a sidecar, bucket output should be internal and destination should be set to
http://localhost:8080/github-webhook/. Copy your input public URL (the one that starts with
https://my.webhookrelay.com/v1/webhooks/....) as you will need it in the next step.
- Go to your GitHub repository settings, then click on “Webhooks” and add your Webhook Relay public URL:
Content type should be JSON.
In this tutorial we are using a slightly customized Jenkins image that has Golang. There’s no reason to add it if you are not using Go. Our Dockerfile:
If you want to build your own image, just add any necessary steps and run:
Now, it’s time to deploy our Jenkins instance. Save this file and use
kubectl to deploy.
You should see something like this:
Since we are using minikube:
Now, you should see Jenkins login screen. Let’s retrieve the password:
Let’s choose ‘Freestyle Project’:
After creating a new job, go to Source Code Management. Now, set Repository URL with your GitHub repository address and tick GitHub hook trigger for GITScm polling. The idea here is that once any push event happens, GitHub will send a webhook and your Jenkins will clone the repository to do the build:
In the build step we will just add a simple ‘Execute shell’ step:
Save the job.
Now, whenever we push to GitHub, a webhook will be sent through Webhook Relay sidecar to the Jenkins in a secure way. Your Jenkins instance will not be exposed to the internet; only one path at
http://localhost:8080/github-webhook/ will be able to accept HTTP requests from outside.
If you go to your Webhook Relay
jenkins bucket details, you should see a new request being delivered:
And our Jenkins job result:
Once the configuration is in place, you can set the same Webhook Relay input endpoint URL to multiple GitHub repositories. Jenkins GitHub plugin will start correct jobs based on webhook contents.
P.S. If you are not using Kubernetes, check out my other blog post about receiving webhooks on Jenkins without public IP.