This GitHub repo is a template that I made to show you how it all works. You can use it right away to run the sample server (httpbin-go) and see the GitHub Action in...action. Relevant threads include https://news.ycombinator.com/item?id=32596212 .
ngrok http 80 --verify-webhook=slack --verify-webhook-secret=[secret]
with a ton of providers out of the box: https://ngrok.com/docs/cloud-edge#webhook-verification
Also, we recently launched https://webhooks.fyi/ to serve as a community resource to capture patterns & practices around webhook implementations. That's a github pages site so pull requests welcome!
Disclosure: I work at ngrok and helped create webhooks.fyi :)
openziti simplifies scale:
+ mTLS
+ zero trust w/ inbound firewall rule of deny-all (rather than ACLs)
+ private DNS w/ wildcard domains
note: mTLS, wildcard domains etc are in ngrok $900/user annual plan but these are free for foss like the OpenZiti solution used by OP (and maybe free for other solutions too?)
One simple approach I take to solve this issue is by whitelisting (using ufw/VPS firewall) Github's webhook IPs listed at https://api.github.com/meta
This works flawlessly while keeping your CI server secure.
The current list has 4 IPv4 IP range and upon checking my server firewall(last updated 3 years ago), I can see I have the first 3 entries in there.
So in the last 3 years, Github has added 1 new IP range which is missing from my server but even then, no webhook call has ever failed to my CI server.
As a precaution I just updated my server firewall right now.
You could of course write a cron script to regularly check Github hooks IPs and update firewall if Github changes it's webhooks IPs.
ipset create ghwebhooks hash:net
iptables -A INPUT -m set --match-set ghwebhooks src -m tcp --dport 443 -j ALLOW
# in /etc/cron.daily
ipset add ...
ipset del ...
ipset list ...
ipset save >/etc/ipset.confIn the past, I've had good luck using a webhook proxy. I've mostly just used https://smee.io/ which is simple and lightweight although seems to be mostly abandonware at this point. I dockerized it so that it could be used in a Kubernetes cluster, which was very useful for my GitHub Actions build cluster: https://github.com/ethomson/smee-client
There's also Hookdeck, which I haven't used in production, but have played around with, and it seems conceptually the same, but can be made more Enterprisey. Whether that's a bug or a feature is probably up to you.
Basically, you set up your GitHub webhook URL as the proxy server (for example, smee.io). Then you run a client on your local machine that connects to the proxy server. When a webhook is fired, it will be sent to the proxy, then delivered to the connected client, which will then pass it along as a webhook to whatever machine you've configured.
There's disadvantages to having all this stuff running, of course, so I think that handling this at the networking layer instead of putting a proxy just for webhooks into place is an interesting strategy. Certainly, it sounds like the right solution if you're already using OpenZiti.
Another related option is that you can run GitHub Runners in your own environment and they will connect to GitHub to accept "jobs" from GitHub Actions. This is another thing we've started doing as we look to pare down our self managed CI. This is a very solid choice I think. In case anyone is interested: https://docs.github.com/en/actions/hosting-your-own-runners/...