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.
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
(read/write for the owner only).
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.