VSTS integration with on-prem Octopus. (How to secure? Best practice?)

security

#1

I know similar questions have been asked before but I think the answers only go as far as confirming that in the case of VSTS hosted agents and an on-prem Octopus server, the only way to get full Octopus deploy integration working is to expose the Octopus API endpoint publicly.

I’m more interested specifically in the best practice for doing this with minimum security risk and whether the Octopus team themselves (or others that have actually done this) believe this to be a sensible/safe/secure enough thing to do. There has been discussion around restricting by IP address ranges but it seems this is not really feasible as there is no definitive list of where the VSTS agents may reside now or in future. That would leave us exposing our Octopus API to the whole world - how secure is that in practice?

For a bit more backgroud - we already have setup a VSTS hosted NuGet feed that Octopus can see and deploy packages from. We are looking to move to continuous deployment in VSTS so it needs to be able to actually trigger Octopus deployments not just push packages into the feed. I understand another option would be to host the build agents ourselves but we’re not keen to do that and I’m not sure it actually solves the deployment part (is a build agent used at all by VSTS for the simple step of “deploy this Octopus package to Production”)?

Any guidance or experiences shared would help.


(Michael Noonan) #3

Hi!

Thanks for getting in touch! We do this ourselves, but as you say, are relying on the built-in security measures in Octopus and Windows, but as you say, we are exposing the HTTP API to the entire world (without IP restrictions). We use Google Apps as our primary user authentication with multi-factor as a requirement. We use Octopus API keys for the VSTS integration.

If you genuinely aren’t comfortable with that approach, here are some thoughts (no silver bullets unfortunately):

  1. Run a VSTS build agent in your Octopus Server network for the sole purpose of driving the Octopus API. This comes with the tradeoffs you’ve mentioned.
  2. Try to figure out the VSTS IP address ranges, either via their support channel, or via network analysis, and then use IP Restrictions.
  3. Consider https://octopus.com/cloud where we take care of the security for you, but again, without IP restrictions.
  4. Create some action on this suggestion: https://octopusdeploy.uservoice.com/forums/170787-general/suggestions/19148905-support-automatic-release-creation-from-external-p

In case it helps, we have recently published some guidance on hardening your Octopus: https://octopus.com/docs/administration/security/hardening-octopus

Hope that helps!
Mike