Here is an idea that I was drafting on Frills, but then I thought it was a bit too open-ended so I’m posting it here for discussion.
So, when you deploy development or staging applications, or production applications for an internal use, you usually don’t want them to be exposed publicly on the internet. You want something that only allows the company employees to access them.
I think that deploying OpenVPN / Wireguard and offering to expose these applications behind an internal ingress, with an easy way to download the VPN configuration files per user, would be extremely practical. From a business perspective, you could even charge for VPN users that are not developers already on Qovery.
An other option I can see would be to deploy an authentication proxy that you can only pass if you’re a known user, like OAuth2 Proxy. Or even just configure the ingress to add an HTTP Basic Auth per application or environment. But these two options are not really practical for backend applications / APIs, only frontend or fullstack applications.
I think it’s a good idea - as far as I know, I’ve seen one of our users building a portal on top of Qovery to allow dev environment access to allowed developers. One of the simplest solutions would be to use Cloudflare Access - which is exactly made for this purpose. You also have Auth0/Okta proposing the same kind of feature as Cloudflare Access.
It looks great and quite similar to the solutions above. Did you try it?
And just like Oauth2 Proxy and alike, that’s probably not very practical for backend applications / APIs.
No, it’s just something I benchmarked in a previous life. There are quite a bunch of more or less similar tools: S.S. Octopus, Vouch Proxy, Authelia, Dex, etc.
The IP whitelisting could work but that would require me to:
set up a VPN so that we all have the same exit IP to handle remote work
automate through the API the modification of ingress rules for all application of my development environment
I’m not considering the basic auth because I’m mainly looking for a way to protect our backend services (we’re already protecting frontend services with Vercel authentication).
An internal-external switch in Qovery would be much more handy.
I will take out the shovel and dig into my memory because I did this kind of thing in the past (~7 years ago) with OpenVPN.
Since we released the Lifecycle Jobs, you can use them to deploy Helm charts or Kubernetes files. As you may know Wireguard is far more simple and secure than OpenVPN. But also younger.
To be fully transparent, I don’t know and didn’t look at what AWS has built or not in the Kernel deployed with EKS. So I can’t guaranty it will work. But what is sure is
OpenVPN: will require TUN or TAP device to be built in the Kerne to run. So it requires Kubernetes elevated privileges for the pod running OpenVPN.
You can IP whitelist only Cloudflare IP ranges, and then other domain will be unreachable. We use it successfully in our organization. Unless you want to use Qovery domains. It would be great if we could bring our own domains to Qovery (for preview environments).
A few of our customers already does it (only cloudflare is supported), it’s not yet integrated at all in the product, but as soon as we’ll get more demand for this, we’ll make it available product side
