The zero trust principles are a series of concepts that pertain to how trust between peers should be handled (affecting authentication, authorization, context and access control).
I guess an example would make sense (especially in the context of Cloudflare). One part of Cloudflare’s business model is being at the edge of technology, develop the tools to make accessible to people, instill in them the urge to swap/move to/use that shiny thing and make businesses pay for it. I’m aware what I am saying may sound sarcastic but they are a company: their purpose is to make money. That being said, I like Cloudflare (or at least that part of them) as they are doing an excellent job technically and most of what they release is clean and actually not at all gimmicky (contrary to what my tone might make you believe).
Regarding VPNs (as actual Virtual Private Networks, with many possible topologies, not as “a proxy that is encrypted so we might as well use that acronym”), they have been the forefront of enterprise ‘“‘security’”’ for a while now (with a recent spike in the past 3-5 years). By that I mean, nothing is accessible from the outside, behind a firewall but once you are inside, it’s open bar. Typically in most places, all users, once inside the VPN, can access about anything and everything, from poorly configured AD, sometimes to direct access to DBs and “legacy” services that only accept 4-number/6-character pins/passwords, etc.
So if a company serves a web page accessible form the outside, they will do it on Web Instance server for example. As they don’t really do proper devops, they need SSH/FTP access to dump new versions of the website on there. They have a DB too on DB Instance. It’s not really accessible from the outside thanks to firewall rules but it’s the same thing: sometimes they need to work on the DB directly so some sort of access must be provided. Then one day there is a breach or Head of IT went to a conference and figured those accesses are not something that should generally be given to just everyone (though SSH is mostly fine if configured correctly, but Head of IT is mostly a Windows guy who hasn’t done anything technical for the past 20 years so they wouldn’t know). So they direct the team to put those accesses behind a VPN. They use a vendor bastion/gateway or implement their own. That bastion literally is in the same network as Web Instance and DB Instance so now magically everything is “protected” by the VPN. Except that anyone connecting to the VPN has access to them. It is not fine-grained. One compromised machine can have access to everything. That’s why companies are now using MFA more and more on their VPN: since that’s basically the only protecting they have and they implicitly trust anyone who gets inside, they must make sure their perimeter is as solid as possible.
Cloudflare deemed this state of affair utter shite: it looks good on paper but security is the Titanic story over and over and over again. It is insanely rare that companies get compromised because of a major blunder. It’s minor stuff that accumulate and finally open a breach that lets attackers in. I.e. it’s not a question of how hard your wall is, it’s a question of “what if an attacker went through the wall anyway?”. Bad security people will say “it won’t happen”. And when it does, they freak out and start using MFA. And when it does again, they freak out and start using bowel scans as 3rd factor (of course an exaggeration but that’s how it feels for a user). The point of zero trust is to put things in place so that the VPN is only one element of security, i.e. going through is not enough to compromise anything (or very limited things).
So how does Cloudflare improves on this? Basically Web Instance and DB Instance won’t be able to see anything at all in the network. Any connection will be established using a provisioning mechanism including access control. So DB Instance will be provided with the key for Web Instance with access control instructions like “the machine behind that key will connect from network device X and can have access to the DB listening on port Y on localhost and I am the one who will establish the connection”. Conversely, Web Instance will be provisioned with DB Instance’s public key and access control like “the machine behind that key will establish a tunnel on network device X and will provide DB access on port Y”. Now if User A connects and they try to connect to DB Instance, they don’t have the key, they don’t have the correct access control rules, they can’t even see it existing at all.
What if User A should have FTP access to Web Instance? With cloudflared correctly configured (or any VPN really, cloudflared uses wireguard under the hood), Web Server will initiate and establish a specific tunnel with a Gateway to expose the FTP server internally. User A will be provided with Gateway. They will establish a connection to Gateway which will check (access control) what resources User A is authorized to access the FTP server provided on the other side by Web Server. If yes, then Gateway will expose the FTP server to User A. If User B can only access DB Server through SSH (exposed on Gateway too), they will only see that and will know nothing about the FTP server Web Instance exposes.
As you can see, none of that applies to what you do: it’s adding a fair bit of complexity for, at best, the same end result. As other said, use wireguard and forget about it.