Security
ClusterRunner was designed to be general-purpose (runs any shell command) and easy to setup/operate (deploys across machines automatically, provides an HTTP REST API). Any system with these properies is going to raise security concerns, and ClusterRunner is no exception. Below are the security considerations you should be aware of.
Message Authentication
If an attacker could send arbitrary requests to a ClusterRunner slave, she could instuct the slave to clone any
repository and execute malicious commands from the repo’s clusterrunner.yaml. To defend against this, each API route
which could result in arbitrary command execution requires a hashed message authentication digest. These
digests are generated using a shared secret, stored in clusterrunner.conf. Slaves cannot communicate with a master
unless both machines have the same secret in their clusterrunner.conf. Using clusterrunner deploy
automatically
distributes the secret to slaves via SSH.
To protect the secret, ClusterRunner requires the permissions for clusterrunner.conf to be 0x600
(read/write for the owner only).
Deploying Slaves
ClusterRunner uses SSH to deploy slave services to remote machines when clusterrunner deploy
is run. This requires
you to have passwordless SSH configured between the local machine and each slave, password-authenticated SSH is not an option.
Unknown host warnings ignored
Any "unknown host" warnings produced by SSH are ignored by default. If you are concerned that the identity of your slave hosts may be spoofed, set git_strict_host_key_checking = true in your ~/.clusterrunner/clusterrunner.conf file. You will need to manually SSH to each slave first and approve its addition to known_hosts.