Outlyer protects all its systems and data using industry best practices. Below provides more details on aspects specific to the Outlyer service.
The Outlyer Agent connects outbound on port 443 only.
Installation of the Outlyer Agent can be done in a number of ways. Most of our customers use configuration management tools and the repos provided in the public Outlyer package repositories. These are extremely simple; they add a repo file, install the outlyer-agent package, modify a config file and start a service.
By default the Outlyer Agent runs as a non privileged user
outlyer which can be locked down further by the operating
system if required.
The Outlyer Agent uses an non privileged account key to join Outlyer and all data is sent over HTTPS/SSL.
By default we only send back basic operating system metrics like CPU, disk, memory, network, and a process list and some metadata about your hosts. This metadata includes things like network addresses, environment variables, and metadata from services like AWS. We send all of this data back for the sole purpose of helping you to troubleshoot issues and for auto discovery of services, so that we can automate the setup of your monitoring. We will never share this data with any 3rd party.
Outlyer has a unique technology that allows teams outside of operations to quickly write plugins and deploy them to groups of servers. We recommend that this feature is enabled and used in development and test so that you get the full value out of our self service capability.
In some cases, usually on production or in more tightly controlled environments you will need to turn off these capabilities.
For this scenario we provide Solo mode which completely disables remote script execution and deployment. This is as simple as
updating the agent.yaml with
solo: true and restarting the service.
In Solo Mode the Outlyer Agent no longer polls the Outlyer API for plugin downloads and instead polls the local disk. Drop all of your plugins into the plugins directory and the Outlyer Agent will still only load those configured in the app. This means you keep the benefit of rapid script creation and deployment, while retaining control of what runs on your servers via your normal config management workflow.