Atlassian uses cookies to improve your browsing experience, perform analytics and research, and conduct advertising. Accept all cookies to indicate that you agree to our use of cookies on your device. Atlassian cookies and tracking notice, (opens new window)
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.
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:
devoeamanagerserveronemandatory - 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.
deaagentpackagermandatory - 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 / providedcertificatesmandatory - 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: openssl_csr – Generate OpenSSL Certificate Signing Request (CSR) — Ansible Documentation).
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.
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.
FQDN of the Load Balancer. 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 Load Balancer.
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.
deam_redis_passwd
REDIS password.
deam_mysql_address
MySQL address and port.
deam_mysql_database
Name of the database to be used by EA Manager. The database should have been created in advance. Check the Using existing databases section.
deam_mysql_username
Username to access the database.
deam_mysql_password
Password to access the database.
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.
For each host, configure the following parameters.
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
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.
For a user and password-based authentication method, the configuration for the host should look like the one in the following snippet:
Alternatively, use the following code in order to use a private key:
all:
...
hosts:
devo-ea-manager:
ansible_host: 192.168.57.5
ansible_user: ssh_user
ansible_ssh_private_key_file: << PATH TO YOUR SSH KEY HERE >>
...
Adding the path to the private key in the inventory file is not mandatory. It can be added to the environment using ssh-add 'key file' instead of adding it to the inventory file.
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
The Devo EA installation process is not standalone and requires Internet access for the installation to be successful. If the server does not have Internet access and requires a proxy to be able to communicate to the external world, please use the following configurations:
Please note that these configurations are outside of the EA Manager product. The following instructions are provided as recommendations to the customer and may have high variability depending on the system and specific scenario.
Depending on the system being deployed, append the following two lines in the corresponding file depending on the Linux distribution the EA Manager will be installed on:
Append the following line to the file /etc/sudoers:
Defaults env_keep = "http_proxy https_proxy"
Append the following line to the file /etc/ssh/sshd_config:
PermitUserEnvironment=yes
Reload the ssh service: sudo systemctl reload sshd
In some cases, the Devo EA Manager may need to be deployed on a server with a very limited outbound Internet connectivity. The following list is a compilation of outbound domains that would need to be specifically opened in the firewall so the Devo EA Deployer can be executed properly:
Take into count that the mirror list is dynamic and the package manager will automatically choose the better one, usually based on location and availability. You may need to enable other mirrors based on your distribution.
Take into count that the mirror list is dynamic and the package manager will automatically choose the better one, usually based on location and availability. You may need to enable other mirrors based on your distribution.
*.centos.org
For CentOS repositories
Take into count that the mirror list is dynamic and the package manager will automaticaly choose the better one, usually based on location and availability. You may need to enable other mirrors based on your distribution.
There are other domains/URLs whose connections must be granted in the event that only the installation of the dockerized version of MySQL and Redis is configured (see the Using Deployer DB self-deployment chapter below):
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.
Load Balancers should have two HTTPs listeners, in port 8080 and in port 8081, as there will be two different services. TCP listeners are not supported by the Devo EA Manager.
Load Balancers should present the same certificate to the endpoints as the EA Manager. When using self-signed certificates created automatically by the deployer, the certificate can be found in /etc/devo-ea-manager/certs after the installation process is completed.
To add a secondary Devo EA Manager, add a new host in the all.hosts section and instruct that the EA Manager role should be installed on it in the children section. See the following code snippet as an example:
In the above example, two hosts are declared (devo-ea-manager and devo-ea-manager-2) in the hosts section. In the children section, the Deployer is instructed to install the EA Manager in devo-ea-manager and a replica in devo-ea-manager-2.
To enable the secondary manager to also provide the Agents' download service in port 8081, it is necessary to explicitly instruct the Deployer to enable that option in the inventory file. See the following code snippet as an example:
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.
The Deployer can install a dockerized version of MySQL and Redis both in the same server than the EA Manager runs or in a different server.
The parameters that need to be configured for both databases are the following:
deam_redis_address - IP and port of the server that will host Redis.
deam_mysql_address - IP and port of the server that will host MySQL.
Optional parameters (if the following parameters are not included in the inventory file, the default value is used):
deam_redis_password - Password of the Redis instance, if it exists. In case Redis does not use a password, set the value as "". Default value: ""
deam_mysql_database - Name of the database to be used. Default value: kolide
deam_mysql_username - Name of the user to access the database. Default value: kolide
deam_mysql_password - Password of the user to access the database. Default value: kolide
Standalone deployment
If the database dockers are going to be installed in the same server as the UA Manager, the role deamintsrvs must be configured to be deployed to the devo-ea-manager host.
This snippet indicates that the role deamintsrvs (MySQL and Redis) will be deployed in the host devo-ea-manager which is defined as well in the inventory file. Check the example configuration files to get some ideas on what your inventory file should look like.
Distributed deployment
If the databases are going to be installed on a different server than the EA Manager, the role deamintsrvs should be configured to be deployed to a different host:
In the example above, a new host named deam-int-services is defined and the Deployer is instructed to install the database services on it. The host information is included inside the all.hosts tag, so the deployer will know where and how to connect to the new server.
In distributed deployments it is important to make sure all necessary configurations to enable visibility between services—between the EAM and the databases, for example—is done beforehand (enabling traffic through the designated ports in any intermediary firewalls).
Devo Endpoint Agent Deployer allows the option of using existing deployments of MySQL and Redis. This solution should be the one to be observed to enable full HA scenarios.
Prepare the MySQL database
When using an existing MySQL database, it is necessary to manually create the database structures and the credentials that the EA Manager will use to interact with it.
Access the MySQL instance with root credentials (or create database privilege granted):
mysql -uuser -ppasword
Create the database to be used by EA Manager (the database name can be changed, deamDB is just an example):
CREATE DATABASE deamDB;
Grant ALL PRIVILEGES over the database to the user that DEAM will use (both username and password can be changed, the following is just an example):
GRANT ALL PRIVILEGES ON deamDB.* TO 'deamUser'@'%' IDENTIFIED BY 'deamPassword';
Prepare the Redis database
No specific configurations in Redis are required other than having full accessibility to the database and valid credentials (password) to access it.
Prepare the EA Deployer
The parameters that control the DB deployment in Devo EA Deployer are the following:
deam_redis_address - VIP and port of Redis instance/cluster.
deam_mysql_address - VIP and port of MySQL instance/cluster.
deam_redis_password - Password of the Redis instance, if it exists. In case Redis use no password, input ““.
deam_mysql_database - Name of the database to be used.
deam_mysql_username - Name of the user to access the database.
deam_mysql_password - Password of the user to access the database.
When an existing database is used, make sure to remove the deamintsrvs from the installation plan in the inventory file. This will instruct the deployer to not deploy any database automatically. If a snippet like the following exists in the inventory file inside all.children tag, remove it:
deamintsrvs:
hosts:
devo-ea-manager:
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:
#dea_ap_repo_user: Username required by _Devo EA packager_ repository for basic authentication. Default value `dea-agent`
dea_ap_repo_user: dea-agent
#dea_ap_repo_passwd: Password required by _Devo EA packager_ repository for basic authentication. Default value `Th3Ag3nt!`
dea_ap_repo_passwd: Th3Ag3nt!
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.
The Devo EA Deployer is configured to generate self-signed certificates and configure them by default.
You can provide your own key or certificate when you run deploy EA Manager using Devo EA Deployer.
To do this, replace the selfsigenedcertificates section with providedcertificates in the inventory file (at same yaml level).
Only one of these sections can be present in the inventory file.
Inventory file with self-signed certificates generation:
selfsigenedcertificates: # Alternative providedcertificates
hosts:
devo-ea-manager:
Inventory file with provided certificates:
providedcertificates:
hosts:
devo-ea-manager:
Save your devo-ea-manager.key and devo-ea-manager.crt files in devo-ea-deployer/provided-deam-certs path. Provided certs must match with the entry point used by DEA agents to connect with EA Manager.
Example inventory files
The following code shows a deployment inventory file that enables the installation of two Devo EA Managers, with customized usernames and passwords, and leveraging on an existing MySQL and Redis deployment ( customer-provided). Endpoints connectivity is enabled via FQDN:
all:
vars:
#deam_fqdnname: Put the Load Balancer FQDN here. This FQDN will be used by the endpoints to reach the EA Manager
deam_fqdnname: loadbalancer_fqdn.com
set_deam_fqdnname_as_hostname: false
dea_ap_builder_update_etc_host: "no"
#deam_redis_address: Input here the VIP and port for the Redis cluster
deam_redis_address: 10.0.0.24:6379
#deam_redis_password: Redis service password. If there is no password, input ""
deam_redis_password: password
#deam_mysql_address: Input here the VIP and port for the MySQL cluster
deam_mysql_address: 10.0.0.60:3306
#deam_mysql_database: Input here the database name
deam_mysql_database: databasename
#deam_mysql_username: MySQL user name. User must have enough permissions to create schema, tables, views, etc.
deam_mysql_username: user
#deam_mysql_password: MySQL password
deam_mysql_password: password
deam_relay_entrypoint: tcp://us.elb.relay.logtrust.net:443
#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!`
deam_admin_passwd: Th3Adm1n!
#dea_ap_repo_user: Username required by _Devo EA packager_ repository for basic authentication. Default value `dea-agent`
dea_ap_repo_user: dea-agent
#dea_ap_repo_passwd: Password required by _Devo EA packager_ repository for basic authentication. Default value `Th3Ag3nt!`
dea_ap_repo_passwd: Th3Ag3nt!
hosts:
#ansible_host: Input IP for Devo EA Manager 1. Can be private, the IP from where the deployer is going to SSH the server for installation tasks.
#ansible_user: SSH user to perform installation tasks
#Depending on the type of SSH user used for the instalation, uncomment the proper lines in each host and fill a value:
#ansible_ssh_pass: Password for the SSH user
#ansible_ssh_private_key_file: Private key path to the used PEM file if not using password
# Only required if you connect with password
#ansible_ssh_common_args: '-o StrictHostKeyChecking=no'
devo-ea-manager:
ansible_host: 10.0.0.10
ansible_user: install_user
#ansible_ssh_pass:
#ansible_ssh_common_args: '-o StrictHostKeyChecking=no'
#ansible_ssh_private_key_file:
ansible_python_interpreter: /usr/bin/python2
devo-ea-manager-2:
ansible_host: 10.0.0.11
ansible_user: install_user
#ansible_ssh_pass:
#ansible_ssh_common_args: '-o StrictHostKeyChecking=no'
#ansible_ssh_private_key_file:
ansible_python_interpreter: /usr/bin/python2
children:
devoeamanagerserverone:
hosts:
devo-ea-manager:
devoeamanagerreplicas:
hosts:
devo-ea-manager-2:
vars:
deam_am_i_replica: true
devoeaagents:
hosts:
deaagentpackager:
hosts:
devo-ea-manager:
devo-ea-manager-2:
vars:
devo_ea_manager_port: 443
selfsigenedcertificates: # Alternative providedcertificates
hosts:
devo-ea-manager:
The following code shows a deployment inventory file that enables an AIO (All In One) deployment. Everything is automatically deployed in the same server, including two dockers running the database services. Endpoint connectivity is enabled via the hosts file.
all:
vars:
deam_fqdnname: devo-ea-manager
deam_redis_address: localhost:6379
deam_mysql_address: localhost:3306
deam_relay_entrypoint: tcp://us.elb.relay.logtrust.net:443
hosts:
devo-ea-manager:
# Set ansible_host your public ip used to conncet from ansbile and devo-ea agents
ansible_host: 192.168.57.5
ansible_user: user
ansible_ssh_pass: 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: /usr/bin/python3
children:
devoeamanagerserverone:
hosts:
devo-ea-manager:
deamintsrvs:
hosts:
devo-ea-manager:
deaagentpackager:
hosts:
devo-ea-manager:
selfsigenedcertificates: # Alternative providedcertificates
hosts:
devo-ea-manager:
devoeaagents:
hosts:
