No no, you are mixing things.
If you want to set up this for an organization then you can definitely restrict the access as well.
To make it easy to understand, let’s assume you have an aws vpc 10.0.0.0/16 (not the default one, assume you created a new one), right?
Now assume you created an instance in the same vpc with CloudFlare tunnel installed in it. To completely get the benefit of tunnel (or in general opening a connection from inside rather than outside by opening a port as it is generally done in cases where a VPN is used) I would suggest you to use the use data scrip for the instance to install cf tunnel and at same time setup a ssh server or for another check you can also create an nginx server.
Do note, do not add any incoming rules to the security group attached to this instance, only add outbound 0.0.0.0/0
Now once your instance is up and running, you can confirm whether your tunnel it up or not by checking the cf tunnel dashboard.
Once you confirm that the tunnel is up and running, now add your vpc’s address to your “private network” under the tunnel configuration.
Now suppose you want to ssh in your instance or access your private nginx server running locally on our instance, you need to turn on your warp client (on whichever device you are trying to access your services from) and login to your cf team in order to access your zero trust (or CloudFlare access).
Before you proceed make sure you also set this vpc’s network range under the “split tunnel” section of your warp client settings.
Once you do that, now you can just directly use any of the ip’s that comes under your vpc’s network with appropriate port mappings and it will be like as in your are inside your vpc accessing your services. But do not that all this traffic is routed via cf’s network.
Now coming to your query about how to restrict access. Make sure you’ve completed all these^.
And to proceed with, go to acces and “add an application” (in this case it will be self hosted) and soon as you do that you’ll have multiple options based on the fact that whether you want to restrict a particular ip:port mapping or the complete network and all the other required options are there once you start adding access policies as per your needs. For instance, you can restrict based on people (say) in your GitHub organization or in your google suite or google application access or emails ending with (say example.com). There are plenty of options you have to make sure that you can access your services normally before proceeding with access policies.
A bonus will be, now assume you’ve another vpc2 and your peer it with vpc1 then one case is that you can ssh in the machine (we discussed^) and directly access resources in peered vpc as well (assuming you’ve not set any complex restrictions based on sg level or subnet level etc.) OR another way is go to your tunnel “private network” config and add this vpc2’s network their as well and you can directly access your services then even from the vpc2.
Once you so this^ you can proceed with the access part, it is not too difficult but having a working setup before you put any access policies will make your understanding a little more easier, I would suggest you to give this a try.