qrkourier

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.

I worked on a minimal self-hosted ziti for Docker here https://github.com/openziti/ziti/tree/release-next/quickstar... and minimal self-hosted zrok (includes ziti) for Docker here https://docs.zrok.io/docs/guides/self-hosting/docker/

...so, basically:

wget https://get.openziti.io/dock/all-in-one/compose.yml docker compose up

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.

I see what you mean. I'll make sure to suggest adding it in those places, then! There's another post about the Python SDK in https://news.ycombinator.com/item?id=32923851 and the repo is https://github.com/openziti/ziti-sdk-py/#readme

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.

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.

That's useful that ngrok has centralized webhook verification! It's meaningful security for the first hop from GitHub to ngrok.

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.

Did you find a way to auto-update your firewall from the dynamic allow list in the GitHub API?

Also relevant, sending a GitHub webhook to private Jenkins server with custom params: https://news.ycombinator.com/item?id=31503429

Re: DNS

.53 is the default for the built-in nameserver in `systemd-resolved`, but there's not collision with the OpenZiti tunneler for Linux because it implements systemd's API and creates a tun device and nameserver in a configurable IP range for which the default is 100.64/10.

A strict VPN is still a perimeter that trusts addresses which are not really identities.

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.

To your point, not all SaaS or vendors with integrations let you run your own code. If they do allow it there's probably an OpenZiti-native way to build-in the connectivity you need.

One alternative is running a tunneler like our users did for their continued access to the Jenkins UI. This is like a VPN client that can run pretty much anywhere, and so there's an excellent chance that it's already in the app store or coming soon for whatever platform you have in mind.

As for an authenticated proxy, thanks for that idea. I do think that a hardened internet edge like that has utility in cases like this, like NGrok + SSO. Another reader suggested their solution involving a third-party queue, essentially offloading the internet exposure problem to a public cloud provider, which is basically what I did here but with different software.

Good job avoiding public internet exposure, but the problem with being "on the VPN" is that it has all the problems of the internet at a smaller scale, so you're still exposed to an untrustworthy network. I'd say that's the core tenant of so-called "zero trust" philosophy.

I think the flexibility of operating independently of IP addresses is the key distinction of this approach. It also works for the web UI, not just the webhooks from GitHub.

Author here, I want to learn more about ZeroTier too. I overlooked it for this project because it supports layer 2 and I needed tighter coupling of application+policy than layer 2 provides. Admittedly, I don't yet know enough about ZeroTier to know if I can disqualify all layer 2 points of contact with a particular policy. It sounds like the layer 2 DNA of ZeroTier tripped you up in this case too.

I know more about OpenZiti than Nebula and will be listening for topics in the Discourse in case you decide to take another stab at it. Nebula is definitely interesting. I got the impression that it's all about automating spin up and tear down of point-to-point VPN tunnels on demand, which has the potential to eliminate much of the headaches around maintaining VPNs. Essentially app and policy configuration driven over hand crafting. That's definitely the approach of OpenZiti too.

Yes: https://github.com/openziti/ziti-sdk-c/

I guess it's like anything else. You can trust someone a little to manage your crypto keys or you can do it yourself whether its PKI or a Bitcoin wallet. You have to know and do more to trust less. For me, it's a really great value if software makes DiY crypto convenient enough to do crypto stuff safely enough that I don't have to trust or pay a 3rd party and don't end up wrecked because I got in over my head. Like bowling bumpers, but for cryptography.

We've all taken that risk at some point. Glad you found a solution!