4 ms·

I recently faced this same challenge and solved it using Amazon SQS, a simple Lambda function, and a corresponding SQS consumer/relay service running inside the

I recently faced this same challenge and solved it using Amazon SQS, a simple Lambda function, and a corresponding SQS consumer/relay service running inside the private LAN. Essentially GitHub's webhook is configured to hit the Lambda function, which authenticates the request and adds the data to an SQS queue. The internal relay service watches that queue and passes requests to the private Jenkins server. The architecture is similar to this[1] project, but since the public-facing piece runs on Lambda, it costs almost nothing to run. [1] https://github.com/osbuild/webhook-relay https://github.com/osbuild/webhook-relay

gz5 4y ago
Looks nice. The key difference seems to be the OpenZiti solution enables you to manage by identities (instead of IP addresses), and close all the inbound firewall ports? However, believe the two solutions would work together?
- dovholuknf 4y ago
  Also embracing OpenZiti allows you to give users access to Jenkins securely (or any other app you want/need to keep off the public internet) without using a classic style VPN.
  - qrkourier 4y ago
    Even if you nail the configuration and have nothing but sweet love for your favorite VPN it's still a perimeter security model and there's no real assurance that only your friends are inside that perimeter. I'll bet you that's not always the case. I don't mean to be ominous but it strikes me as a false sense of security. Going full zero trust is a more meaningful assurance that only authorized devices and apps can connect.
- dperfect 4y ago
  Yes, if you also need users to log into Jenkins from outside the private network (without a VPN), it sounds like OpenZiti would be a good option. In my case, Jenkins is only used from within the LAN. The SQS solution authenticates GitHub webhooks using the sha256 hmac signature (not by IP), and no inbound ports need to be open.
  - dovholuknf 4y ago
    You'll still have open ports on the LAN. With OpenZiti you can even shut down the host firewall from having any open ports which I think is pretty cool. :) Plus you'll be able to access Jenkins from anywhere at that point - even from home - just like you were on the LAN. Maybe you'll find that useful someday in the future and give OpenZiti a try! :)
gizdan 4y ago
This is almost what we do as well. The difference being that we have a API Gateway in front that just invokes the lambda on an internal network, which validates the webhook data and only then does it forward it. Takes the complexity of having to use a queue out of the equation, though at the expense of potentially lost webhook calls.

gz5 4y ago

Looks nice. The key difference seems to be the OpenZiti solution enables you to manage by identities (instead of IP addresses), and close all the inbound firewall ports? However, believe the two solutions would work together?

dovholuknf 4y ago
Also embracing OpenZiti allows you to give users access to Jenkins securely (or any other app you want/need to keep off the public internet) without using a classic style VPN.
- qrkourier 4y ago
  Even if you nail the configuration and have nothing but sweet love for your favorite VPN it's still a perimeter security model and there's no real assurance that only your friends are inside that perimeter. I'll bet you that's not always the case. I don't mean to be ominous but it strikes me as a false sense of security. Going full zero trust is a more meaningful assurance that only authorized devices and apps can connect.
dperfect 4y ago
Yes, if you also need users to log into Jenkins from outside the private network (without a VPN), it sounds like OpenZiti would be a good option. In my case, Jenkins is only used from within the LAN. The SQS solution authenticates GitHub webhooks using the sha256 hmac signature (not by IP), and no inbound ports need to be open.
- dovholuknf 4y ago
  You'll still have open ports on the LAN. With OpenZiti you can even shut down the host firewall from having any open ports which I think is pretty cool. :) Plus you'll be able to access Jenkins from anywhere at that point - even from home - just like you were on the LAN. Maybe you'll find that useful someday in the future and give OpenZiti a try! :)

gizdan 4y ago

This is almost what we do as well. The difference being that we have a API Gateway in front that just invokes the lambda on an internal network, which validates the webhook data and only then does it forward it. Takes the complexity of having to use a queue out of the equation, though at the expense of potentially lost webhook calls.