Securing Octopus Deploy Instance

Apologies if this has been asked before. I would like to understand what options are available for securing traffic to an Octopus Deploy cloud instance from an on-premise or private network. I understand there is the option of whitelisting traffic from tentacles to OD, but that is a control on the private network side, what about traffic to OD itself? If credentials or API keys escaped the organisation then in theory anyone could access the cloud instance from anywhere in the world, including malicious actors. Is there an option to whitelist the traffic which an OD cloud instance will accept, or to set up a VPN between a private network and OD?

Hi @robert_a,

Welcome to the Octopus community! No problem at all, that’s a great question so thanks for reaching out!

As you’ve pointed out, the Octopus Cloud URL is available from anywhere in the world and unfortunately it’s not currently possible to restrict which IP’s can access it, however we do provide controls for invalidating sessions and configuring the timeout.

If greater security controls are needed then we do recommend using our Self Hosted offering over Cloud: Octopus Deploy Licensing & Purchasing FAQ - Octopus Deploy

For these reasons, we recommend Octopus Server when you have specific security or privacy requirements, need to integrate Octopus with your internal Active Directory domain, or when you want to put Octopus as close as possible to the target servers you are deploying software to, and when you are already managing virtual machines and other applications. Octopus Cloud makes more sense if you are primarily deploying applications to the cloud and when you are comfortable entrusting security and backups to us.

Cloud Instances do come with a Static IP range for the cluster, which can be whitelisted to allow access to your internal networks. (Note: this doesn’t apply to the built-in or dynamic workers so we recommend using static workers and can change under certain conditions, which we will do our best to give you at least 30 days notice!)

For this reason we typically recommend Polling Tentacles for Cloud Instances as it requires only allowing outbound traffic from your internal network rather than inbound. We’ve also just released Polling Tentacles over 443 so that it can use a standard port simplifying the firewall rules needed!

I’d definitely recommend checking out our Security docs as well as our Trust Center which has more details about how we secure and audit our product.

Hope that helps but feel free to reach out with any questions or if I can clarify anything further!

Best Regards,

Thanks for the reply. Are there any plans to address this issue?

Hey @robert_a,

Thank you for the reply, unfortunately there wont be any plans to change our infrastructure since we host it for you we are unable to let customers have control over our firewalls to restrict IP addresses.

If we did restrict IPs it would be very difficult for customers to use tentacles with Octopus Cloud considering the tentacles can be hosted on any platform with any IP address.

Our cloud offering instances are hosted in Kubernetes Pods which uses a few main firewalls so it would be impossible for us to restrict IP addresses for individual pods (instances).

As Finnian mentioned, we have quite a few bits of documentation on how our cloud instances are hosted and how we address security and auditing.

If your audit requirements for your organisation require you to restrict access to the Octopus instance for certain IP addresses as Finnian mentioned we do have an Octopus self hosted server offering where you control the infrastructure so would be able to restrict IP addresses as you are the ones hosting the server and all the networking requirements for that instance.

Hopefully our documentation covers everything you need to know but unfortunately there are no plans to allow the restriction of IP addresses to an Octopus Cloud instance.

Kind Regards,

This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.