At a glance, the RunPod's serverless and pod options would probably work well with OpenZiti. I didn't explore their vLLM option.
Using OpenZiti w/ Serverless probably means integrating an OpenZiti SDK with your serverless application. That way, it'll connect to the OpenZiti network every time it spawns.
The SDK option works anywhere you can deploy your application because it doesn't need any sidecar, agent, proxy, etc, so it's definitely the most flexible and I can give you some examples if you mention the language or framework you're using.
The pod option says "container based" so it'll take some investigation to find out if an OpenZiti sidecar or other tunneling proxy is an option. Would you be looking to publish something running in RunPod (the server is in RunPod), or access something elsewhere from a RunPod pod (the client is in RunPod), or both?
> This is awesome -- I really like my current admission controller though (Traefik), it's FANTASTIC. I think moving ingress controllers might be a large lift for people (it would be for me).
Clarification: You could use Traefik's ingress controller in tandem with a hypothetical OpenZiti ingress controller. You'd set `ingressClass: openziti` on those Ingress resources you wish OpenZiti to handle. Nothing would prevent you from creating two Ingress resources for the same ClusterIP service: one each for Traefik and OpenZiti.
True, the tools used by risk managers will have to adapt to overlays if overlays (software defined networks that look like encrypted noise on the wire) are as inevitable as they appear to be. It's kind of an arms race and it only makes sense to embrace what's happening and invest in those tools that bring the controls and insights that are needed by defensive security interests to do their job.
At the same time overlays move security closer to the app which shifts the purview left even further toward the developer. This might mean that developers will bear more of the burden of ensuring a secure deployment by choosing a good overlay and effectively operating that overlay in a way that satisfies Security and Compliance.
That's a neat angle. I reckon you could position the self-hosted runner network-adjacent a private CI server and poke it directly from behind the firewall with a GitHub Actions job.
The proxy idea is interesting too. Does a webhook proxy entail a polling model for events? That is, does the private server have to poll the proxy to receive the webhook? I wanted the GitHub event to push to trigger actions on the private server.
No - your local server will still listen for webhooks, but they'll come from the proxy's client software.
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.
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.
Glad you got it updated before you missed an event! That's the worry that made me look for something flexible and software-defined that I could run in GitHub Actions.
The bigger worry would be if they removed some IP addresses from their list. Those IP addresses would be juicy targets for hackers to scoop up and attempt an attack knowing that people have whitelisted them and that they allow access to what is likely relatively poorly protected infrastructure.
I was doing this with Cloudflare IPs, and iptables as the firewall. Pretty simple bash script scheduled with crontab worked just fine. Was doing this on a DD-WRT flashed netgear router. There's probably something similar that can be done here
I do something similar for AWS IPs in our iptables firewalls. I create an ipset for "aws", and then create rules that match that ipset. I then have a script that runs periodically and downloads the set of AWS IPs (AWS publishes that) and writes then runs the script that creates the ipset.
Using OpenZiti w/ Serverless probably means integrating an OpenZiti SDK with your serverless application. That way, it'll connect to the OpenZiti network every time it spawns.
The SDK option works anywhere you can deploy your application because it doesn't need any sidecar, agent, proxy, etc, so it's definitely the most flexible and I can give you some examples if you mention the language or framework you're using.
The pod option says "container based" so it'll take some investigation to find out if an OpenZiti sidecar or other tunneling proxy is an option. Would you be looking to publish something running in RunPod (the server is in RunPod), or access something elsewhere from a RunPod pod (the client is in RunPod), or both?