Some deployment technologies are designed for the LAN and have no security at all. Some require machines to be on the same Active Directory domain. Others require you to set up usernames and passwords, and to store them in configuration files.
When designing Octopus, we wanted to make it easy to have secure deployments out of the box, without expecting machines to be on the same domain and without sharing passwords. Octopus needed to work in scenarios where the Octopus Deploy server is running in your local LAN, close to your developers, while your production servers are running in the cloud or at a remote data center.
We achieve this security using public-key cryptography.
Regardless of whether Tentacle is in listening mode or polling mode, all communication between the Tentacle and Octopus is performed over HTTPS. Octopus and Tentacle both have a public/private key pair, that they use to establish the HTTPS connection (one is the TLS server and presents a server certificate, the other is a TLS client and presents a client certificate).
When Tentacle is configured, you give it the thumbprint (which uniquely identifies the public key) of the Octopus server. Likewise, you tell Octopus the thumbprint of the Tentacle. This establishes a trust relationship between the two machines:
- Your Octopus server will only issue commands to the Tentacles that it trusts
- Your Tentacles only accept commands from an Octopus they trust
The only way another system can impersonate either party is by getting hold of the private key, which are kept safe and never leave the Octopus/Tentacle server (unless you export them from the certificate store). This makes it much more secure than exchanging passwords.
Since this is all based on public-key cryptography, it creates a highly secure way for the two machines to communicate without exchanging passwords, and works much like an SSH connection in the UNIX world. If necessary you can further restrict access using IPSec or VPN's.
The X.509 certificates used by Octopus are generated on installation and use 2048-bit private keys. The TLS implementation uses the SslStream class from the .NET Framework, and uses TLS 1.0 (fallback to SSL is not allowed).