Generic deployment guidelines

[ 1 The inventory ] [ 2 Deployment credentials ] [ 3 Initial packs configuration ] [ 4 Python Interpreter ] [ 5 Endpoint Agent <> EA Manager communication ] [ 6 EA Manager <> Devo communication ] [ 7 Other special deployment cases ] [ 8 High availability configuration ] [ 9 Databases installation ] [ 10 Devo EA Manager users and passwords ] [ 11 Certificates ] [ 12 Example inventory files ]

Depending on the desired deployment scenario, there are a handful of different alternatives that can be approached for a particular customer installation.

The Devo Endpoint Agent installation process is flexible to allow a number of deployment models by using a specific inventory file. In this document, the most common scenarios are depicted, as well as the list of additions to the inventory that are required to fulfill those. Thus, each subsection can be considered as an installation step that offers different alternatives for completion, and not a step-by-step installation procedure.

If there is any special need not covered in this guideline, contact Devo for more detailed information.

The inventory

The deployment of the Endpoint Agent is done via Ansible playbooks. The playbook instruments need steps to deploy the platform according to your needs, defining what and where you want to deploy every component. To do so, the Ansible playbooks use a YAML inventory file (How to build your inventory — Ansible Documentation) to understand what tasks are needed to accomplish this. The YAML inventory file is the core of the deployment and it is very important to have clear what type of deployment you want to achieve and to create a valid inventory file before starting the deployment process.

When preparing a new deployment of the Endpoint Agent, it is important to have in mind some questions:

If you are looking for a PoC or non-productive environment deployment, the standalone All-in-One deployment is provided, where the Ansible playbooks create two dockers with the ancillary services for the EA Manager to run properly.
If you are looking for a small production environment and you do not need HA, you can use the standalone deployment, but use your own ancillary services (MySQL and REDIS) to give the system more robustness and security.
If you are looking for a bigger production deployment enabling HA, you should consider a distributed deployment using several managers and your own DB clusters to ensure robustness, security, and availability. Agents should communicate with the EA Manager via a Load Balancer to enable the use of more than one EA Manager.

The endpoints connect to the manager via /etc/hosts change.
The endpoints connect to the manager with a known FQDN.
The endpoints connect to the manager using a public IP but no FQDN.

Check the packs provided out of the box in Preintegrated query packs.

The Endpoint Agent provides several YAML templates to base your inventory file in, depending on the case that you are trying to deploy. An Ansible YAML inventory file is composed of three main sections:

all -> vars

This section defines all the variables that are going to be used in the tasks during the playbook run.

all -> hosts

This section defines the information related to the hosts where the solution is going to be deployed. It can include one or more hosts, and it is composed of blocks named after the hostname of the destination host.

all -> children

This section defines the topology that is going to be deployed. You can define host groups with a specific name and include the hosts defined in the all->hosts section. The playbook will then deploy specific roles to those groups when it's run.

The pre-defined host groups are the following:

devoeamanagerserverone ^mandatory - First EA Manager server.
devoeamanagerreplicas - Secondary (or more) manager servers. This role needs to include a variable deam_am_i_replica: true in this section.
deamintsrvs - EA Manager required ancillary services that should be enabled only in one host. If this role is included, it creates a docker for MySQL and Redis . If you will be using your own databases, this host group should not be included in the inventory.
deaagentpackager ^mandatory - EA repository that can be enabled in one or more hosts. In each host included in this group, playbook packages osquery installers with certificates and secrets, and generates the auto-installation scripts for the agents that will be deployed in the endpoints. It also installs and configures am NGINX service to easily download said packages.
selfsigenedcertificates / providedcertificates ^mandatory - Only one of these hosts groups can be enabled at the same time and are only required just as in devoeamanagerserverone:
- selfsigenedcertificates - Instruct the EA deployer to generate self-signed certificates that will be used to secure the communication between the endpoints and the manager. By default, the self-signed certificates created by the EA deployer will only trust the FQDN defined in deam_fqdn. In the case you need your certificate to trust different names (for example, to use a public IP and not the FQDN) , you can use the variable SAN_extensions and define a list of Subject Alternative Names (IPs and DNSs) to be included in the certificate (valid format and values: https://docs.ansible.com/ansible/2.9/modules/openssl_csr_module.html#parameter-subject_alt_name).
- providedcertificates - Instruct the EA deployer to use existing certificates instead of creating new ones. You should use this group if you want to use your own certificates for EA Manager.

Standalone deployment template

The below snippet is a valid inventory file for a standalone deployment.

all:
  vars:
    deam_fqdnname: << FQDN >>
    dea_ap_builder_update_etc_host: << yes/no >>
    dea_ap_overwrite_deam_fqdnname: << PUBLIC_HOST_IP >>    
    set_deam_fqdnname_as_hostname: false
    deam_admin_username: << ADMIN_USER >>
    deam_admin_passwd: << ADMIN_PASS >>
    dea_ap_repo_user: << REPO_USER >>
    dea_ap_repo_passwd: << REPO_PASS >>
    deam_redis_address: << REDIS_ADDRESS:PORT >>
    deam_mysql_address: << MYSQL_ADDRESS:PORT >>
    deam_relay_entrypoint: << ENTRYPOINT_URL >>
    deam_packs_enabled:
      - configuration.yaml
      - events.yaml
      - fetchfiles.yaml
      - performance.yaml
      - status.yaml
  hosts:
    << HOST_NAME >>:
      ansible_host: << HOST_IP >>
      ansible_user: << HOST_USER >>
      ansible_ssh_pass: << HOST_PASS >>
      # Only required if you connect with password
      ansible_ssh_common_args: '-o StrictHostKeyChecking=no'
      ansible_python_interpreter: << PYTHON_INTERPRETER >>
  children:
    devoeamanagerserverone:
      hosts:
        << HOST_NAME >>:
    deamintsrvs:
      hosts:
        << HOST_NAME >>:
    deaagentpackager:
      hosts:
        << HOST_NAME >>:
    selfsigenedcertificates: # Alternative providedcertificates
      hosts:
        << HOST_NAME >>:
      vars:
        #If no Subject Alternate Names are required, completely remove the SAN_extensions block.
        SAN_extensions:
        - IP: << HOST_PUBLIC_IP >>
        - DNS: << HOST_FQDN >>
        - DNS: << HOST_FQDN_2 >>

Check the descriptions of the parameters below:

`deam_fqdnname`	FQDN of the EA Manager. Agents will use this FQDN to communicate to the EA Manager.
`dea_ap_builder_update_etc_host`	Indicates if the installation package of the endpoints will update `/etc/hosts` to communicate with the manager. If the FQDN set in deam_fqdnname is public and the agents can reach it, set it as “no”. If the FQDN set in deam_fqdnname is not reachable by the agents and the communication with the EA Manager is via internet, set it as “no”. Configure the parameter `dea_ap_overwrite_deam_fqdnname` with the public IP so that the agents will use it to communicate. If the FQDN set in deam_fqdnname is not reachable by the agents and the communication with the EA Manager is via private network, set it as “yes”. When an agent is deployed, the `/etc/hosts` will be modified to assign the IP configured in ansible_host to the FQDN value.
`dea_ap_overwrite_deam_fqdnname`	If the FQDN is not reachable by the agent, but the manager need to be accessed via the internet, put here the public IP that the agent will use to connect. When using public FQDNs or local connection using `/etc/hosts` this parameter is not necessary and can be removed completely from the inventory.
`set_deam_fqdnname_as_hostname`	This parameter can always be kept as false. It is a legacy parameter that will be deprecated in the future.
`deam_admin_username`	User for the WEB interface of the EA Manager.
`deam_admin_passwd`	Password for the WEB interface of the EA Manager.
`dea_ap_repo_user`	User for the agent download repository.
`dea_ap_repo_passwd`	Password for the agent download repository.
`deam_redis_address`	REDIS address and port: If the deployment is self creating dockers for REDIS and MySQL, the value should be configured as `localhost:6379`. If the deployment is using your own DB services, the value should be configured with the address of the REDIS database and the port of access.
`deam_mysql_address`	MySQL address and port: If the deployment is self creating dockers for REDIS and MySQL, the value should be configured as `localhost:3306`. If the deployment is using your own DB services, the value should be configured with the address of the MySQL database and the port of access.
`deam_relay_entrypoint`	Includes the entry point value of the Devo collector for your deployment: If your domain is deployed in the US Cloud (us.devo.com): `tcp://us.elb.relay.logtrust.net:443`. If your domain is deployed in the EU Cloud (eu.devo.com): `tcp://eu.elb.relay.logtrust.net:443`. If your domain is deployed in a different cloud, contact your Devo representative to know your entry point.
`deam_packs_enabled`	List of YAML files including the definition of the packs that will be deployed into the EA Manager.

`hosts`	The hosts section of the inventory is composed by a group of hosts named with the hostname of the host. In the case of standalone deployment it will include only one. Replace `<< HOST_NAME >>` with the hostname of the server where the installation is happening. Ansible will connect via SSH to every host where it needs to take action using the data configured in this section.
`ansible_host`	IP of the EA Manager server that ansible is going to use to connect to the host.
`ansible_user`	SSH User to connect to this host
`ansible_ssh_pass`	Password for the SSH user. It is not mandatory to use a password when using the playbooks. If you want to use SSH keys, just comment out this parameter and add your ssh key at Linux session level or include it in this section using the parameter `ansible_ssh_private_key_file`
`ansible_python_interpreter`	Specify what python interpreter will be used depending on your Linux distribution and version: Python 2 - `/usr/bin/python2` Python 3 - `/usr/bin/python3`

Distributed deployment template

The following template is a deployment of Endpoint Agent with two EA Managers using existing databases. This deployment also requires a Load Balancer to be placed between the endpoints and the two EA Managers.

all:
  vars:
    deam_fqdnname: << FQDN >>
    dea_ap_builder_update_etc_host: << yes/no >>
    set_deam_fqdnname_as_hostname: false
    deam_admin_username: << ADMIN_USER >>
    deam_admin_passwd: << ADMIN_PASS >>
    dea_ap_repo_user: << REPO_USER >>
    dea_ap_repo_passwd: << REPO_PASS >>
    deam_redis_address: << REDIS_ADDRESS:PORT >>
    deam_redis_password: << REDIS_PASSWORD >>
    deam_mysql_address: << MYSQL_ADDRESS:PORT >>    
    deam_mysql_database: << MYSQL_DATABASE_NAME >>
    deam_mysql_username: << MYSQL_USER >>
    deam_mysql_password: << MYSQL_PASSWORD >>
    deam_relay_entrypoint: << ENTRYPOINT_URL >>
    deam_packs_enabled:
      - configuration.yaml
      - events.yaml
      - fetchfiles.yaml
      - performance.yaml
      - status.yaml
  hosts:
    << HOST_NAME_SERVER_1 >>:
      ansible_host: << HOST_IP >>
      ansible_user: << HOST_USER >>
      ansible_ssh_pass: << HOST_PASS >>
      # Only required if you connect with password
      ansible_ssh_common_args: '-o StrictHostKeyChecking=no'
      ansible_python_interpreter: << PYTHON_INTERPRETER >>
    << HOST_NAME_SERVER_2 >>:
      # Set ansible_host your public ip used to conncet from ansbile and devo-ea agents
      ansible_host: << HOST_IP >>
      ansible_user: << HOST_USER >>
      ansible_ssh_pass: << HOST_PASS >>
      # Only required if you connect with password
      ansible_ssh_common_args: '-o StrictHostKeyChecking=no'
      # python3 required for Ubuntu 18 ansible-playbooks
      ansible_python_interpreter: << PYTHON_INTERPRETER >>
  children:
    devoeamanagerserverone:
      hosts:
        << HOST_NAME_SERVER_1 >>:
    devoeamanagerreplicas:
      hosts:
        << HOST_NAME_SERVER_2 >>:
      vars:
        deam_am_i_replica: true        
    deamintsrvs:
      hosts:
        << HOST_NAME_SERVER_1 >>:
    deaagentpackager:
      hosts:
        << HOST_NAME_SERVER_1 >>:
        << HOST_NAME_SERVER_2 >>:
    selfsigenedcertificates: # Alternative providedcertificates
      hosts:
        << HOST_NAME_SERVER_1 >>:

Check the descriptions of the parameters below:

Deployment credentials

The Devo EA Deployer uses SSH to connect to the different servers where it needs to install different components. When configuring the hosts in the inventory file, it is necessary to configure the SSH user and authentication method that the deployer needs to use in each task.

Initial packs configuration

From v1.1.0 onwards, the Endpoint Agent deployer enables customers to decide which query packs are deployed with the solution, as opposed to all of them being added automatically during the installation process. Therefore, the installer must decide which packs to add to the baseline configuration to fulfill the customer’s particular needs and use cases. The complete list of available packs, along with a description of their functionality and set of supported use cases, can be found in the preintegrated query packs section.

The process to enable packs is handled with two parameters in the inventory file:

1

deam_packs_enabled

Sets what packs to be deployed when running both devo-endpoint-agent and deam-packs playbooks.

In the following example, only the configuration (represented by configuration.yaml) and events (events.yaml) packs are deployed:

The file names included in this list come from the files placed in $HOME/devo-ea-deployer/playbooks/roles/deam-packs/files/optional-devo-packs

2

deam_packs_purge_cached_files

Use this option when you do not want to deploy a pack anymore. Once the packs are deployed for the first time, they are cached under (/var/devo-ea-manager/packs/devo-packs). If you want to avoid some of the packages being redeployed, make sure to include them in the purge list before triggering the deploy operation. Otherwise, the deployer will use the cached version and deploy the packs again even if they are not included in deam_packs_enabled.

In the following example, the installation user is deploying only the configuration.yaml pack and is purging the events.yaml pack that was previously deployed from the temporary folder:

Python Interpreter

When deploying in CentOS 7 or Red Hat 7 OS, make sure that the host is configured to use python 2 instead of python 3 in the inventory file.

Endpoint Agent <> EA Manager communication

EA Manager <> Devo communication

Other special deployment cases

High availability configuration

Some deployment scenarios will require the deployment of more than one EA Manager to cater to all the traffic generated from the endpoints, and to ensure that high availability of the data processing and forwarding is observed. In this case, a specific configuration during the installation process is required to instruct the Devo EA Deployer how to instantiate those roles.

Devo EA Deployer will take care of deploying several EA Managers, but in order to provide a single entry point to the endpoints, it is necessary to set up a Load Balancer separately.

Databases installation

The EAM relies on MySQL and Redis for data (configurations, etc.) persistence. There are several scenarios to consider depending on the type of installation required for a particular customer.

The next section summarizes the most common alternatives for the deployment of the databases, as well as the procedure to implement them.

Devo EA Manager users and passwords

After a successful deployment of Devo EA Manager, two services that require authentication will be created. User and password can be configured to include your own passwords. If these parameters are not included in the inventory file, default values are used.

Devo EA Manager Web Interface (port 8080): To control the user and password for this service, the following parameters can be used in the inventory file:

#deam_admin_username: _Devo EA manager_ username for initial admin user setup. Default value: `admin`
deam_admin_username: admin
#deam_admin_passwd: _Devo EA manager_ password for initial admin user setup. Default value: `Th3Adm1n!`
duam_admin_passwd: Th3Adm1n!

Devo Endpoint Agent download (port 8081): To control the user and password for this service, the following parameters can be used in the inventory file:

Certificates

The Devo EA Deployer is configured to generate self-signed certificates and configure them by default but you can configure EA Deployer to use your own certificates.

It is recommended to use ECDSA certificates instead of RSA as TLS decryption in the EA Manager side is smoother and increases the performance significantly. The EA Deployer will generate ECDSA certificates by default when using self-generated certificates.

Devo v7.10.0