Security is important to us, and we are committed to ensuring that Scout meets the same high standards you maintain for your own servers.
First, we ensure that only our server is sending you plugins. The agent validates the SSL certificate of the Scout server and will only send and receive data if the certificate is validated. This makes a man-in-the-middle-attack practically impossible.
After that, we ensure our server doesn't send you bad plugins. First, we code-review each plugin that is accepted into our directory. We also don't think you should just take our word for it, which is why we show you the code when you add a plugin. This isn't nearly as it involved as it sounds since the majority of plugins are fairly short and straightforward. Second, plugin code is signed via a private key. The agent only executes a plugin if the plugin signature is validated with the associated public key.
In addition to the plugins being available to you, we also keep the agent and plugins open source. One of our major reasons for doing that is to ensure that your security team has full access to the code we are asking you to use on your server.
- You install the Scout Agent (which is a Ruby gem) on your server.
- The agent connects over https (always) through a 256-bit secure, encrypted connection (the same encryption your bank uses).
- Scout never logs in to any of your servers.
- All communication is initiated by the agent — it is impossible for a 3rd party to initiate any operations by contacting the Scout agent.
- The agent downloads a pre-loaded plugin plan, consisting only of plugins of your choosing, so it cannot run plugins you didn’t explicitly authorize.
- The server also uses that same secure encryption for all communication. Individual accounts are protected.
- Agent keys (uniquely generated) can be revoked at any time, disabling the agent.
If you are running plugins from outside our repository, treat them like any other code you introduce into your production environment: make sure it comes from a credible source, and review the source code if you have an doubts.
Most plugins have relatively few lines of code and are easy to review.
You can provide plugin settings via a
plugins.properties file installed on your server vs. the Scout UI. This is useful in the following cases:
- You've installed a plugin template via a role and servers in that role need server-specific plugin settings.
- Plugin settings could change frequently and you don't want to perform those updates via our UI.
- You have sensitive information you'd like to keep on your servers.
There are two steps to use a
/var/lib/scoutd directory on your server create a
# this is a comment line mysql.username=root
- The lookup keys are completely up to you - the only requirement is that what you specify in the web interface must match the keys you supply in
- Multiple plugins can use the same lookup key, so, for example, if you have two plugins using a MySQL password, they can both reference the same key in
- If a plugin in a role uses lookup keys, you'll have to copy plugins.properties to each server in the role.
- When setting up
plugins.properties, we recommend running Scout manually and watching the debug output. It will confirm that it's using
plugin.propertiesas you expect. To run manually with debug output:
scout YOUR_KEY -v -ldebug --f
If you have sensitive plugin settings (like passwords) and would rather keep those locally on your servers, you can use a
plugins.properties file. See Configuration lookups above.