This page describes how Octopus and Tentacle servers communicate in a secure way.
Some deployment technologies have no security at all. Some require a machines to be on the same Active Directory domain, or on the same LAN. 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. A common example is when the Octopus 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.
The Tentacle agent service listens on TCP port 10933 by default, though this can be changed during the installation. Octopus sends commands to it in the form of HTTP requests. These requests are encrypted using a pair of X509 certificates. 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
When you install the Tentacle service, you add a thumbprint for the Octopus servers it should trust. When you register a machine in Octopus, you'll add the thumbprint of the Tentacle.
In the diagram below, you can see the Octopus web portal where machines are registered, and the setup page for the Tentacle agent:
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, though this usually isn't necessary.
The implementation of all of this uses WCF wsHttpBinding (WS-Trust) with message level security and the Basic256 algorithm suite. The following algorithms are used:
- The X509 certificate public/private keys use RSA algorithms with 512 bit keys
- WCF uses those RSA asymmetric keys to exchange a randomly generated symmetric key, which is then used to encrypt all data payloads for the session using AES256
- SHA1 is also used in addition for signing the messages
The algorithms used in this process are provided by Microsoft, and all operate when Use FIPS compliant algorithms is enforced as part of the local security policy. You can view an example of what these messages look like on the wire.
The Tentacle service by default runs as Local System. This is because during deployment of your applications you usually need to perform tasks that require a high-degree of access to the machine, such as configuring IIS and configuring Windows Services.
For the sake of security, however, it's better to create a custom Windows user that has only the permissions you know you'll need. You can then configure the Octopus Tentacle windows service to run under that account.