- Use Case
- Log in →
- Responding to API calls using Node-RED Webhook Relay node
- Docker Compose update on Github webhook
- Using Google Firestore for a Golang backend application
- Automated Jenkins builds on GitHub pull request
- Rules-based webhook filtering & routing
- 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
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
kubectl --namespace default create \\
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:
docker build -t <your dockerhub username>/jenkins-ci:latest -f Dockerfile .
Now, it’s time to deploy our Jenkins instance. Save this file and use
kubectl to deploy.
kubectl create -f deployment.yaml
You should see something like this:
$ kubectl apply -f deployment.yaml
Since we are using minikube:
kubectl get svc
echo $(minikube service jenkins-ci-lb --url)
Now, you should see Jenkins login screen. Let’s retrieve the password:
# token will be on the VM where the Jenkins is running
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:
Started by GitHub push by rusenask
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.