Welcome to the Inedo Forums! Check out the Forums Guide for help getting started.
If you are experiencing any issues with the forum software, please visit the Contact Form on our website and let us know!
Access control by ingress
-
I'm interested to know if anyone has set up Proget with access control varying by ingress. Here's what I'm after:
- Devs on the local network (i.e. in the office or on VPN) can anonymously pull packages for restores, and authenticate to push packages
- CI systems not on the network must authenticate to pull packages for restores, and for pushing packages
It's ok if I need separate host names for each of the above cases, but ideally all the interesting auth parts would happen inside Proget.
How do people secure their Proget servers for package restores?
-
Hi @mharen,
You can try to enable Windows Integrated Authentication in ProGet, and then use two sites in IIS (once with WIA, one without), but that will only work for NuGet packages. Other client (npm, docker) do not support WIA.
Otherwise, you can take a "DMZ" approach, and configure two instances of ProGet - one for Devs, one for CI systems - then use a connector. The two-instance approach also has the benefit of reducing load, though not quite as much as a load balancing configurating.
Cheers,
Alana
-
Thank you for your help! I am hoping that this is enough to lock down nuget restores:
API Keys for Pulling/Listing Packages
Most clients will not send the API key for operations like listing or pulling packages. In this case, ProGet will issue an authentication challenge, and the client will respond by prompting for a username and password. In this case, you can supply api for the username, and your API key for the password.I'll test that.
