Kaspersky Next XDR Expert

Migrating KUMA standalone to Kaspersky Next XDR Expert

Expand all | Collapse all

This article covers transferring data and services from KUMA standalone to Kaspersky Next XDR Expert.

After the migration is complete, all services of KUMA standalone are reconnected to KUMA Core under Kaspersky Next XDR Expert, and then the services are automatically restarted. KUMA standalone Core is not modified during migration, but if any services were installed on the same host as the KUMA standalone Core, the KUMA standalone Core may become unavailable, since the binary files are replaced during the course of the procedure.

Migration from KUMA standalone to Kaspersky Next XDR Expert proceeds in stages:

  1. Creating a token

    In KUMA standalone, generate a new token for a user who has rights to execute the /api/v1/system/backup request, and keep the token in a safe place. Later, you specify the new token to create a backup copy for KUMA standalone.

  2. Preparing the hosts for installation of Kaspersky Next XDR Expert

    When preparing the hosts for installation of Kaspersky Next XDR Expert, do the following:

    • Verify that you opened the required ports.
    • Verify that you have SSH root access to the target hosts of KUMA standalone and access from Kaspersky Next XDR Expert worker nodes to port TCP 7223 of the deployed KUMA standalone. If necessary, run the following command to grant SSH root access to the target hosts of KUMA standalone:

      ssh-copy-id -i /home/xdr/.ssh/id_rsa.pub <user>@<ip_kuma>

  3. Creating a backup copy

    Before you perform the migration, create a backup copy for KUMA standalone and keep the backup in a safe place. You will be able to restore the instance of KUMA standalone and repeat the migration all over again. Otherwise, in case of a failure, KUMA Core may be corrupted and you will not be able to perform the migration.

    Before you create a backup copy, verify that KUMA Core in Kaspersky Next XDR Expert has network access to the API ports of KUMA standalone services.

    You can create a backup copy in one of the following ways:

    • Using the REST API.
    • Using the following command:

      curl -sS -k "https://<KUMA_standalone_core_FQDN>:7223/api/v1/system/backup" -H "Authorization: Bearer $(cat standalone_token)" --output kuma_standalone_backup.tar.gz

      Where standalone_token is the token that you previously generated in KUMA standalone. Also, you can specify the token instead of $(cat standalone_token).

  4. Preparing the inventory file for migration

    Prepare the inventory file. In the inventory file, list all hosts that you use for services in KUMA standalone. The hosts must match in both inventory files: the one you used for KUMA standalone deployment and the one you are going to use for migration. If necessary, you can get the required information regarding hosts in KUMA standalone, in the Resources → Active services section.

    If you want to expand the infrastructure and deploy KUMA services while performing the migration, make sure that you specify the additional hosts in the inventory file, and that the designation of hosts that you listed for migration in the inventory file remains unchanged.

    The path to the inventory file that you prepared is specified in the multinode.smp_param.yaml or singlenode.smp_param.yaml file in the inventory parameter.

    When preparing the inventory file, observe the following conditions:

    • In the kuma_utils group of parameters, specify hosts with services. Also, in this group of parameters, if you want to expand the infrastructure along with the migration, you can specify new hosts where KUMA services are to be deployed.
    • For all hosts, specify both the FQDN and IP addresses.
    • Skip the kuma_core section.
    • In the all group of parameters, avoid changing the ansible_connection and ansible_user variables, since the variables correspond to the user and the type of connection used for invocation image.
    • In the kuma group of parameters, verify that the ansible_connection and ansible_user variables correspond to the user who performs the installation on the remote hosts. For details about the inventory file, users, and rights, refer to KUMA help.
    • If DNS resolves all names, you can specify false for the generate_etc_hosts parameter or skip the generate_etc_hosts parameter.

    Sample of the inventory.yaml with KUMA standalone services installed on a single host

    Sample of the inventory.yaml with KUMA standalone services installed on multiple hosts

  5. Migration

    At this stage of the scenario, perform the migration:

    1. Place the KUMA standalone backup copy on the target host where you are going to install Kaspersky Next XDR Expert.
    2. On the administrator host, run the following command with the kuma_backup_file parameter. Specify the path to the transport archive with the Kaspersky Next XDR Expert components and the path to the prepared multinode.smp_param.yaml or singlenode.smp_param.yaml file, same as for initial installation.

      ./kdt apply -k <path_to_transport_archive> -i <path_to_configuration_file> --accept-eula -p --if kuma_backup_file=./<kuma_standalone_backup>.tar.gz

    After the migration is complete, all services connect to KUMA Core in Kaspersky Next XDR Expert and become available in KUMA Console under Resources → Active services.

    If KUMA standalone Core was installed on an individual host, after you perform the migration, KUMA standalone Core maintains the option to address the services migrated to Kaspersky Next XDR Expert. In this case, service statuses are displayed and you are able to restart the services, change the services configuration, get the service log, and view the events. To avoid this, you can use any of the following options:

    • Before you perform the migration, disable KUMA standalone Core.
    • After you perform the migration, in Kaspersky Next XDR Expert, go to KUMA Console SettingsCommon, click Reissue internal CA certificates, and then run the following command and wait until KUMA Core and all services are restarted in Kaspersky Next XDR Expert:

      ./kdt invoke kuma --action resetServicesCert