Kaspersky Next XDR Expert
[Topic 273808]

Preparing the administrator and target hosts

The administrator host is used to deploy and manage the Kubernetes cluster and Kaspersky Next XDR Expert. The target hosts are included in the Kubernetes cluster and perform the workload of the Kaspersky Next XDR Expert components. Kaspersky Next XDR Expert is deployed on the target hosts by using KDT. KDT runs on the administrator host and connects to target hosts via SSH.

Before installing Kaspersky Next XDR Expert, we recommend that you run the following command on the administrator and target hosts:
apt update

Preparing the administrator host

To prepare the administrator host:

  1. Prepare a device that will act as an administrator host from which KDT will launch.

    The administrator host will not be included in the Kubernetes cluster that is created by KDT during the deployment.

    Make sure that the hardware and software on the administrator host meet the requirements for KDT.

    On the administrator host, allocate at least 10 GB of free space in the temporary files directory (/tmp) for KDT. If you do not have enough free space in this directory, run the following command to specify the path to another directory:

    export TMPDIR=<new_directory>/tmp

  2. Install the package for Docker version 20 or later, and then perform post-installation steps to configure the administration host for proper functioning with Docker.

Preparing the target hosts

To prepare the target hosts:

  1. Prepare the physical or virtual machines on which Kaspersky Next XDR Expert will be deployed.

    A minimum cluster configuration for the distributed deployment includes four nodes:

    • One primary node

      The primary node is intended for managing the cluster, storing metadata, and distributing of the workload.

    • Three worker nodes

      The worker nodes are intended for performing the workload of the Kaspersky Next XDR Expert components.

      For optimal allocation of computing resources, it is recommended to use nodes with the same resources.

      You can install the DBMS inside the Kubernetes cluster when you perform the demonstration deployment of Kaspersky Next XDR Expert. In this case, allocate the additional worker node for the DBMS installation. KDT will install the DBMS during the Kaspersky Next XDR Expert deployment.

      For the distributed deployment, we recommend installing a DBMS on a separate server outside the cluster.
      After you deploy Kaspersky Next XDR Expert, changing the DBMS installed inside the cluster to a DBMS installed on a separate server is not available. You have to remove all Kaspersky Next XDR Expert components, and then install Kaspersky Next XDR Expert again. In this case, the data will be lost.

    A minimum cluster configuration for the single node deployment includes one target host, which acts as the primary and worker nodes. On this primary/worker node, the Kubernetes cluster and Kaspersky Next XDR Expert components are installed.

    Make sure that the hardware and software on the target hosts meet the requirements for the selected deployment option (the distributed or single node deployment), and the target hosts are located in the same broadcast domain.

    For proper functioning of Kaspersky Next XDR Expert the Linux kernel version must be 5.15.0.107 or later on the target hosts with the Ubuntu family operating systems

    Do not install Docker on the selected target hosts. KDT will install all necessary software and dependencies during the deployment.

  2. On each target host, install the sudo package, if this package is not already installed. For Debian family operating systems, install the UFW package on the target hosts.
  3. On each target host, configure the /etc/environment file, if your organization's infrastructure uses the proxy server to access the internet, as well as you need to connect the target hosts to the internet.
  4. On the primary node with the UFW configuration, allow IP forwarding. In the /etc/default/ufw file, set DEFAULT_FORWARD_POLICY to ACCEPT.
  5. Provide access to the package repository where the packages required for the function of Kaspersky Next XDR Expert are located:
    • nfs-common
    • tar
    • iscsi-package
    • wireguard
    • wireguard-tools

    KDT will try to install these packages during the deployment from the package repository. You can also install these packages manually.

  6. Ensure that the curl package is installed on the primary node (or on the primary/worker node, if you perform the single node deployment).
  7. Ensure that the libnfs12 package is installed on the worker nodes (or on the primary/worker node, if you perform the single node deployment).

    The curl and libnfs12 packages are not installed during the deployment from the package repository by using KDT. You must install these packages manually if they are not already installed.

  8. Reserve static IP addresses for the target hosts, for the Kubernetes cluster gateway, and for the DBMS (if the DBMS is installed inside the cluster).

    The Kubernetes cluster gateway is intended for connecting to the Kaspersky Next XDR Expert components installed inside the Kubernetes cluster.

  9. On your DNS server, register the domain names to connect to the Kaspersky Next XDR Expert services.

    By default, the Kaspersky Next XDR Expert services are available at the following addresses:

    • console.<smp_domain>—Access to the OSMP Console functionality.
    • admsrv.<smp_domain>—Access to the Administration Server functionality.
    • kuma.<smp_domain>—Access to the KUMA functionality.
    • api.<smp_domain>—Access to the Kaspersky Next XDR Expert API functionality.
    • psql.<smp_domain>—Interaction with the DBMS (PostgreSQL).

      Register the psql.<smp_domain> domain name if you installed the DBMS inside the Kubernetes cluster on the DBMS node and you need to connect to the DBMS.

    The listed domain names must correspond to the IP address of the Kubernetes cluster gateway. If you install the DBMS inside the cluster, the gateway IP address is an IP range. The first IP address of the range is the address of the Kaspersky Next XDR Expert services (excluding the DBMS IP address), and the second IP address of the range is the DBMS IP address.

  10. On the target hosts, create user accounts that will be used for the Kaspersky Next XDR Expert deployment.

    These accounts are used for the SSH connection and must be able to elevate privileges (sudo) without entering a password. To do this, add the created user accounts to the /etc/sudoers file.

  11. Configure the SSH connection between the administrator and target hosts:
    1. On the administrator host, generate SSH keys by using the ssh-keygen utility.
    2. After you generate a pair of SSH keys, copy the public key to every target host (for example, to the /home/<user_name>/.ssh directory).
  12. For proper function of the Kaspersky Next XDR Expert components, provide network access between the target hosts and open the required ports on the firewall of the administrator and target hosts, if necessary.
  13. Configure time synchronization over Network Time Protocol (NTP) on the administrator and target hosts.
  14. If necessary, prepare custom certificates for working with Kaspersky Next XDR Expert public services.

    You can use one intermediate certificate that is issued off the organization's root certificate or leaf certificates for each of the services. The prepared custom certificates will be used instead of a self-signed certificates.

Page top
[Topic 249228]

Preparing the hosts for installation of the KUMA services

The KUMA services (collectors, correlators, and storages) are installed on the KUMA target hosts that are located outside the Kubernetes cluster.

To prepare the KUMA target hosts for installation of the KUMA services:

  1. Ensure that hardware, software, and installation requirements are met.
  2. Specify the host names.

    We recommend specifying the FQDN, for example: kuma1.example.com.

    We do not recommend changing the KUMA host name after installation. This will make it impossible to verify the authenticity of certificates and will disrupt the network communication between the application components.

  3. Configure the SSH connection between the administrator host and hosts on which the KUMA services will be installed.

    You can use the SSH keys created for the target hosts. Alternatively, you can generate new SSH keys by using the ssh-keygen utility:

    1. On the administrator host, generate SSH keys by using the ssh-keygen utility without a passphrase.
    2. Copy the public key to hosts on which the KUMA services will be installed by using the ssh-copy-id utility.
  4. Register the KUMA target hosts in your organization's DNS zone to allow host names to be translated to IP addresses.
  5. To get the hostname that you must specify in the KUMA inventory file, run the following command:

    hostname -f

    The prepared hosts must provide access for the administrator host by the hostname.

The hosts are ready for installation of the KUMA services.

Page top
[Topic 265298]

Installing a database management system

Kaspersky Next XDR Expert supports PostgreSQL or Postgres Pro database management systems (DBMS). For the full list of supported DBMSs, refer to the Hardware and software requirements.

Each of the following Kaspersky Next XDR Expert components requires a database:

  • Administration Server
  • Automation Platform
  • Incident Response Platform (IRP)
  • Identity and Access Manager (IAM)

Each of the components must have a separate database within the same instance of DBMS. We recommend that you install the DBMS instance outside the Kubernetes cluster.

For the DBMS installation, KDT requires a privileged DBMS account that has permissions to create databases and other DBMS accounts. KDT uses this privileged DBMS account to create the databases and other DBMS accounts required for the Kaspersky Next XDR Expert components.

For information about how to install the selected DBMS, refer to its documentation.

After you install the DBMS, you need to configure the DBMS server parameters to optimize the DBMS work with Open Single Management Platform.

Page top
[Topic 166761]

Configuring the PostgreSQL or Postgres Pro server for working with Open Single Management Platform

Kaspersky Next XDR Expert supports PostgreSQL or Postgres Pro database management systems (DBMS). For the full list of supported DBMSs, refer to the Hardware and software requirements. Consider configuring the DBMS server parameters to optimize the DBMS work with Administration Server.

The default path to the configuration file is: /etc/postgresql/<VERSION>/main/postgresql.conf

Recommended parameters for PostgreSQL and Postgres Pro DBMS for work with Administration Server:

  • shared_buffers = 25% of the RAM value of the device where the DBMS is installed

    If RAM is less than 1 GB, then leave the default value.

  • max_stack_depth = If the DBMS is installed on a Linux device: maximum stack size (execute the 'ulimit -s' command to obtain this value in KB) minus the 1 MB safety margin

    If the DBMS is installed on a Windows device, then leave the default value 2 MB.

  • temp_buffers = 24MB
  • work_mem = 16MB
  • max_connections = 151
  • max_parallel_workers_per_gather = 0
  • maintenance_work_mem = 128 MB

Restart or reload the server after updating the postgresql.conf file to apply changes. Refer to the PostgreSQL documentation for details.

Refer to the following topic for details on how to create and configure accounts for PostgreSQL and Postgres Pro: Configuring accounts for work with PostgreSQL and Postgres Pro.

For detailed information about PostgreSQL and Postgres Pro server parameters and on how to specify the parameters, refer to the corresponding DBMS documentation.

See also

Installing a database management system

Page top
[Topic 241223]

Preparing the KUMA inventory file

Expand all | Collapse all

The KUMA inventory file is a file in the YAML format that contains installation parameters for deployment of the KUMA services that are not included in the Kubernetes cluster. The path to the KUMA inventory file is included in the configuration file that is used by Kaspersky Deployment Toolkit for the Kaspersky Next XDR Expert deployment.

The templates of the KUMA inventory file are located in the distribution package. If you want to install the KUMA services (storage, collector, and correlator) on one host, use the single.inventory.yaml file. To install the services on several hosts in the network infrastructure, use the distributed.inventory.yaml file.

We recommend backing up the KUMA inventory file that you used to install the KUMA services. You can use it to remove KUMA.

To prepare the KUMA inventory file,

Open the KUMA inventory file template located in the distribution package, and then edit the variables in the inventory file.

The KUMA inventory file contains the following blocks:

  • all block

    The all block contains the variables that are applied to all hosts specified in the inventory file. The variables are located in the vars section.

  • kuma block

    The kuma block contains the variables that are applied to hosts on which the KUMA services will be installed. These hosts are listed in the kuma block in the children section. The variables are located in the vars section.

The following table lists possible variables, their descriptions, possible values, and blocks of the KUMA inventory file where these variables can be located.

List of possible variables in the vars section

Variable

Description

Possible values

Block

Variables located in the vars section of the all and kuma blocks

ansible_connection

Method used to connect to the KUMA service hosts.

  • ssh—Connection to the target hosts via SSH is established.
  • local—No connection to the target hosts is established.

To provide the correct installation of the KUMA services, in the all block, set the ansible_connection variable to local.

In the kuma block, you must specify this variable and set ansible_connection to ssh to provide the connection to the hosts on which the KUMA services are installed via SSH.

  • all
  • kuma

ansible_user

User name used to connect to KUMA service hosts to install external KUMA services.

If the root user is blocked on the target hosts, specify a user name that has the right to establish SSH connections and elevate privileges by using su or sudo.

To provide the correct installation of the KUMA services, in the all block, set the ansible_user variable to nonroot.

In the kuma block, you must override this variable and set ansible_user to a username of the account that can connect to remote hosts via SSH, to prepare them for the installation of the KUMA services.

  • all
  • kuma

deploy_example_services

Variable used to indicate the need to increase the privileges of the user account that is used to install KUMA components.

  • false—No services are needed. The default value for the KUMA inventory file template.
  • true—Services must be created.

To provide the correct installation of the KUMA services, in the all block, set the deploy_example_services variable to false.

all

ansible_become

Variable used to indicate the need to increase the privileges of the user account that is used to install KUMA components.

  • false—If the ansible_user value is root.
  • true—If the ansible_user value is not root.

kuma

ansible_become_method

Method used for increasing the privileges of the user account that is used to install KUMA components.

su or sudo if the ansible_user value is not root.

kuma

Variables located in the children section of the kuma block

kuma_utils

Group of hosts used for storing the service files and utilities of KUMA.

A host can be included in the kuma_utils group and in the kuma_collector, kuma_correlator, or kuma_storage group at the same time. The kuma_utils group can contain multiple hosts.

During the Kaspersky Next XDR Expert deployment, on the hosts that are included in kuma_utils, the following files are copied to the /opt/kaspersky/kuma/utils/ directory:

  • kuma is an executable file with which the KUMA services are installed.
  • kuma.exe is an executable file with which the KUMA agents are installed on Windows-based hosts.
  • LEGAL_NOTICES is a file with information about third-party code.
  • maxpatrol-tool, kuma-ptvm.tar.gz are utilities for integration with MaxPatrol.
  • ootb-content is an archive with out of the box resources for the KUMA services.

The group of hosts contains the ansible_host variable that specifies the unique host FQDN and IP address.

kuma

kuma_collector

Group of KUMA collector hosts. This group can contain multiple hosts.

The group of KUMA collector hosts contains the ansible_host variable that specifies the unique host FQDN and IP address.

kuma

kuma_correlator

Group of KUMA correlator hosts. This group can contain multiple hosts.

The group of KUMA correlator hosts contains the ansible_host variable that specifies the unique host FQDN and IP address.

kuma

kuma_storage

Group of KUMA storage hosts. This group can contain multiple hosts.

The group of KUMA storage hosts contains the ansible_host variable that specifies the unique host FQDN and IP address.

kuma

Sample of the KUMA inventory file template for installation of the KUMA services on a single host (the single.inventory.yaml file)

all:

vars:

deploy_example_services: false

ansible_connection: local

ansible_user: nonroot

kuma:

vars:

ansible_connection: ssh

ansible_user: root

children:

kuma_utils:

hosts:

kuma.example.com:

ansible_host: 0.0.0.0

kuma_collector:

hosts:

kuma.example.com:

ansible_host: 0.0.0.0

kuma_correlator:

hosts:

kuma.example.com:

ansible_host: 0.0.0.0

kuma_storage:

hosts:

kuma.example.com:

ansible_host: 0.0.0.0

shard: 1

replica: 1

keeper: 1

Sample of the KUMA inventory file template for installation of the KUMA services on several hosts (the distributed.inventory.yaml file)

all:

vars:

deploy_example_services: false

ansible_connection: local

ansible_user: nonroot

kuma:

vars:

ansible_connection: ssh

ansible_user: root

children:

kuma_utils:

hosts:

kuma-utils.example.com:

ansible_host: 0.0.0.0

kuma_collector:

hosts:

kuma-collector-1.example.com:

ansible_host: 0.0.0.0

kuma_correlator:

hosts:

kuma-correlator-1.example.com:

ansible_host: 0.0.0.0

kuma_storage:

hosts:

kuma-storage-1.example.com:

ansible_host: 0.0.0.0

shard: 1

replica: 1

keeper: 1

kuma-storage-2.example.com:

ansible_host: 0.0.0.0

shard: 1

replica: 2

keeper: 2

kuma-storage-3.example.com:

ansible_host: 0.0.0.0

shard: 2

replica: 1

keeper: 3

kuma-storage-4.example.com:

ansible_host: 0.0.0.0

shard: 2

replica: 2

Page top
[Topic 265307]

Distributed deployment: Specifying the installation parameters

Expand all | Collapse all

The configuration file is a file in the YAML format and contains a set of installation parameters for the Kaspersky Next XDR Expert components.

The installation parameters listed in the tables below are required for the distributed deployment of Kaspersky Next XDR Expert. To deploy Kaspersky Next XDR Expert on a single node, use the configuration file that contains the installation parameters specific for the single node deployment.

The template of the configuration file (smp_param.yaml.template) is located in the distribution package in the archive with the KDT utility. You can fill out the configuration file template manually; or use the Configuration wizard to specify the installation parameters that are required for the Kaspersky Next XDR Expert deployment, and then generate the configuration file.

For correct function of KDT with the configuration file, enter an empty line at the end of the file.

The nodes section of the configuration file contains the target host parameters that are listed in the table below.

Installation parameters of the nodes section

Parameter name

Required

Description

desc

Yes

The name of the node.

type

Yes

The node type.

Possible parameter values:

  • primary
  • worker

host

Yes

The IP address of the node. All nodes must be included in the same subnet.

kind

No

The node type that specifies the Kaspersky Next XDR Expert component that will be installed on this node.

Possible parameter values:

  • admsrv—The value for the node on which Administration Server will be installed.
  • db—The value for the node on which the DBMS will be installed. It is used if you want to install the DBMS on the node inside the cluster.

For Kaspersky Next XDR Expert to work correctly, we recommend that you select the node on which Administration Server will work. Also, you can select the node on which you want to install the DBMS. Specify the appropriate values of the kind parameter for these nodes. Do not specify this parameter for other nodes.

user

Yes

The username of the user account created on the target host and used for connection to the node by KDT.

key

Yes

The path to the private part of the SSH key located on the administrator host and used for connection to the node by KDT.

The parameters section of the configuration file contains the parameters listed in the table below.

Installation parameters of the parameters section

Parameter name

Required

Description

psql_dsn

Yes

The connection string for accessing the DBMS that is installed and configured on a separate server. 

Specify this parameter as follows: psql_dsn=postgres://<dbms_username>:<password>@<fqdn>:<port>.

dbms_username—The user name of a privileged internal DBMS account. This account is granted permissions to create databases and other DBMS accounts. By using this privileged DBMS account, the databases and other DBMS accounts required for the Kaspersky Next XDR Expert components will be created during the deployment. 

password—The password of the privileged internal DBMS account.

fqdn:port—The FQDN and connection port of a separate server on which the DBMS is installed.

If the psql_dsn parameter is set, the Kaspersky Next XDR Expert components use the DBMS located at the specified FQDN. Otherwise, the Kaspersky Next XDR Expert components use the DBMS inside the cluster.

We recommend installing a DBMS on a separate server outside the cluster.
After you deploy Kaspersky Next XDR Expert, changing the DBMS installed inside the cluster to a DBMS installed on a separate server is not available.

nwc-language

Yes

The language of the OSMP Console interface specified by default. After installation, you can change the OSMP Console language.

Possible parameter values:

  • enUS
  • ruRu

ipaddress

Yes

The reserved static IP address of the Kubernetes cluster gateway. The gateway must be included in the same subnet as all cluster nodes.

If you install the DBMS on a separate server, the gateway IP address must contain the subnet mask /32.

If you install the DBMS inside the cluster, set the gateway IP address to an IP range in the format 0.0.0.0-0.0.0.0, where the first IP address of the range is the gateway IP address itself and the second IP address of the range is the DBMS IP address.

ssh_pk

Yes

The path to the private part of the SSH key located on the administrator host and used for connection to the node by KDT.

sshKey

Yes

The path to the private part of the SSH key located on the administrator host and used for connection to the nodes with the KUMA services (collectors, correlators, and storages).

kscpassword

adminPassword

Yes

The kscpassword and adminPassword parameters specify the password of the same Kaspersky Next XDR Expert user account that will be created by KDT during the installation. The default username of this account is "admin".

The Main administrator role is assigned to this user account.

The kscpassword and adminPassword parameter values must match.

The adminPassword parameter is used for uploading the KUMA license and out-of-the-box resources.

The password must comply with the following rules:

  • The user password cannot have fewer than 8 or more than 16 characters.
  • The password must contain characters from at least three of the groups listed below:
    • Uppercase letters (A–Z)
    • Lowercase letters (a–z)
    • Numbers (0–9)
    • Special characters (@ # $ % ^ & * - _ ! + = [ ] { } | : ' , . ? / \ ` ~ " ( ) ;)

lowResources

No

The parameter that indicates that Kaspersky Next XDR Expert is installed on the target host with limited computing resources.

Set the lowResources parameter to false for distributed deployment.

Possible parameter values:

  • true
  • false

coreDiskRequest

Yes

The parameter that specifies the amount of disk space for the operation of KUMA Core. This parameter is used only if the lowResources parameter is set to false. If the lowResources parameter is set to true, the coreDiskRequest parameter is ignored and 4 GB of the disk space for the operation of KUMA Core is allocated. If you do not specify the coreDiskRequest parameter and the lowResources parameter is set to false, the default amount of disk space for the operation of KUMA Core is allocated. The default amount of disk space is 512 GB.

inventory

Yes

The path to the KUMA inventory file located on the administrator host. The inventory file contains the installation parameters for deployment of the KUMA services that are not included in the Kubernetes cluster.

hostInventory

No

The path to the additional KUMA inventory file located on the administrator host. This file contains the installation parameters used to partially add or remove hosts with the KUMA services.

If you perform an initial deployment of Kaspersky Next XDR Expert or you do not need to partially add or remove hosts with the KUMA services, set this parameter to /dev/null.

license

Yes

The path to the license key of KUMA.

smp_domain

Yes

The domain name that is used in the addresses of the public Kaspersky Next XDR Expert services.

pki_domain

Yes

The domain name for which a self-signed or custom certificate is to be generated. The pki_domain and smp_domain parameter values must match.

iam-nwc_host

flow_host

hydra_host

login_host

admsrv_fqdn

console_fqdn

api_fqdn

kuma_fqdn

psql_fqdn

monitoring_fqdn

coreIngressHost

gateway_host

hydra_fqdn

IAMHydraServerPublicExternal

Yes

The addresses of the Kaspersky Next XDR Expert services. These addresses contain the domain name, which must match the smp_domain parameter value.

pki_fqdn_list

Yes

The list of addresses of the public Kaspersky Next XDR Expert services for which a self-signed or custom certificate is to be generated. These addresses contain the domain name, which must match the smp_domain parameter value.

intermediate_bundle

No

The path to the custom intermediate certificate used to work with public Kaspersky Next XDR Expert services.

intermediate_enabled

No

The parameter that indicates whether to use the custom intermediate certificate instead of the self-signed certificates for the public Kaspersky Next XDR Expert services.

Possible parameter values:

  • true
  • false

admsrv_bundle

api_bundle

console_bundle

psql_bundle

No

The paths to the custom leaf certificates used to work with the corresponding public Kaspersky Next XDR Expert services: admsrv.<smp_domain>, api.<smp_domain>, console.<smp_domain>, psql.<smp_domain>. Specify the psql_bundle parameter if you installed the DBMS inside the Kubernetes cluster on the DBMS node.

If you want to specify the leaf custom certificates, set the intermediate_enabled parameter to false and do not specify the intermediate_bundle parameter.

KUMAUIURL

Yes

The address of KUMA Console. This address contains the domain name, which must match the smp_domain parameter value.

webConsoleURL

Yes

The address of OSMP Console. This address contains the domain name, which must match the smp_domain parameter value.

encrypt_secret

sign_secret

Yes

The names of the secret files that are stored in the Kubernetes cluster. These names contain the domain name, which must match the smp_domain parameter value.

ksc_state_size

Yes

The amount of free disk space allocated to store the Administration Server data (updates, installation packages, and other internal service data). Measured in gigabytes, specified as "<amount>Gi". The required amount of free disk space depends on the number of managed devices and other parameters, and can be calculated. The minimum recommended value is 10 GB.

kdtStateSize

No

The amount of free disk space allocated to store the internal service KDT data. Measured in gigabytes, specified as "<amount>Gi". The minimum recommended value is 1 GB.

ksc_backup_size

Yes

The amount of free disk space allocated to store the backups of the Administration Server data. Measured in gigabytes, specified as "<amount>Gi".The minimum recommended value is 10 GB.

prometheus_size

Yes

The amount of free disk space allocated to store metrics. Measured in gigabytes, specified as "<amount>GB". The minimum recommended value is 5 GB.

loki_size

Yes

The amount of free disk space allocated to store OSMP logs. Measured in gigabytes, specified as "<amount>Gi". The minimum recommended value is 20 GB.

adminLogin

Yes

The adminLogin parameter specifies the username of the Kaspersky Next XDR Expert user account that will be created by KDT during the installation. This parameter is used for uploading KUMA resources.

The adminLogin and kumaLogin parameter values must match.

The default parameter value is admin. Do not change the parameter value.

psql_tls_off

No

The parameter that indicates whether to encrypt the traffic between the Kaspersky Next XDR Expert components and the DBMS by using the TLS protocol.

Possible parameter values:

  • true
  • false

psql_trusted_cas

No

The path to the PEM file that can contain the TLS certificate of the DBMS server or a root certificate from which the TLS server certificate can be issued.

psql_client_certificate

No

The path to the PEM file that contains a certificate and a private key of the Kaspersky Next XDR Expert component. This certificate is used to establish the TLS connection between the Kaspersky Next XDR Expert components and the DBMS.

proxy_enabled

No

The parameter that indicates whether to use the proxy server to connect the Kaspersky Next XDR Expert components to the internet. If the host on which Kaspersky Next XDR Expert is installed has internet access, you can also provide internet access for operation of Kaspersky Next XDR Expert components (for example, Administration Server) and for specific integrations, both Kaspersky and third-party. To establish the proxy connection, you must also specify the proxy server parameters in the Administration Server properties.

Possible parameter values:

  • true
  • false

proxy_addresses

No

The IP address of the proxy server. If the proxy server uses multiple IP addresses, specify these addresses separated by a space (for example, "0.0.0.0 0.0.0.1 0.0.0.2").

proxy_port

No

The number of the port through which the proxy connection will be established.

psql_ns

psql_instance

kumaUrl

kumaLogin

Yes

Parameters for internal use. Do not change the parameter value.

Sample of the configuration file for the distributed deployment of Kaspersky Next XDR Expert

schemaType: ParameterSet

schemaVersion: 1.0.1

namespace: ""

name: bootstrap

project: xdr

nodes:

- desc: cdt-primary1

type: primary

host: 1.1.1.1

kind:

access:

ssh:

user: root

key: /root/.ssh/id_rsa

- desc: cdt-w1

type: worker

host: 1.1.1.1

kind:

access:

ssh:

user: root

key: /root/.ssh/id_rsa

- desc: cdt-w2

type: worker

host: 1.1.1.1

kind:

access:

ssh:

user: root

key: /root/.ssh/id_rsa

- desc: cdt-w3

type: worker

host: 1.1.1.1

kind: admsrv

access:

ssh:

user: root

key: /root/.ssh/id_rsa

parameters:

- name: psql_ns

source:

value: ""

- name: psql_instance

source:

value: ""

- name: psql_dsn

source:

value: "postgres://postgres:password@dbms.example.com:1234"

- name: nwc-language

source:

value: "enUS"

- name: ipaddress

source:

value: 1.1.1.1/32

- name: ssh_pk

source:

path: /root/.ssh/id_rsa

- name: sshKey

source:

path: /root/.ssh/id_rsa

- name: kscpassword

source:

value: "password"

- name: adminPassword

source:

value: "password"

- name: lowResources

source:

value: "false"

- name: inventory

source:

value: "/root/osmp/inventory.yaml"

- name: hostInventory

source:

value: "/dev/null"

- name: license

source:

value: "/root/osmp/license.key"

- name: smp_domain

source:

value: "smp.local"

- name: pki_domain

source:

value: "smp.local"

- name: iam-nwc_host

source:

value: "console.smp.local"

- name: flow_host

source:

value: "console.smp.local"

- name: hydra_host

source:

value: "console.smp.local"

- name: login_host

source:

value: "console.smp.local"

- name: admsrv_fqdn

source:

value: "admsrv.smp.local"

- name: console_fqdn

source:

value: "console.smp.local"

- name: api_fqdn

source:

value: "api.smp.local"

- name: kuma_fqdn

source:

value: "kuma.smp.local"

- name: psql_fqdn

source:

value: "psql.smp.local"

- name: monitoring_fqdn

source:

value: "monitoring.smp.local"

- name: coreIngressHost

source:

value: kuma.smp.local

- name: gateway_host

source:

value: console.smp.local

- name: hydra_fqdn

source:

value: console.smp.local

- name: KUMAUIURL

source:

value: https://kuma.smp.local:7220

- name: webConsoleURL

source:

value: https://console.smp.local:443

- name: IAMHydraServerPublicExternal

source:

value: "https://console.smp.local:443"

- name: pki_fqdn_list

source:

value: "admsrv.smp.local api.smp.local console.smp.local kuma.smp.local psql.smp.local monitoring.smp.local"

- name: encrypt_secret

source:

value: "ksc.encrypt.smp.local"

- name: sign_secret

source:

value: "iam.sign.smp.local"

- name: ksc_state_size

source:

value: "20Gi"

- name: ksc_backup_size

source:

value: "10Gi"

- name: prometheus_size

source:

value: "10GB"

- name: loki_size

source:

value: "20Gi"

- name: kumaUrl

source:

value: "http://core.kuma.svc.cluster.local:7220"

- name: kumaLogin

source:

value: "admin"

- name: adminLogin

source:

value: "admin"

- name: intermediate_bundle

source:

path: "./bundle.pem"

- name: intermediate_enabled

source:

value: "true"

- name: admsrv_bundle

source:

path: "/dev/null"

- name: api_bundle

source:

path: "/dev/null"

- name: console_bundle

source:

path: "/dev/null"

- name: psql_bundle

source:

path: "/dev/null"

- name: psql_tls_off

type: string

default: "true"

- name: psql_trusted_cas

type: file

- name: psql_client_certificate

type: file

- name: proxy_enabled

source:

value: "true"

- name: proxy_addresses

source:

value: "0.0.0.0 0.0.0.1 0.0.0.2"

- name: proxy_port

source:

value: "8080"

Page top
[Topic 249240]

Distributed deployment: Installing Kaspersky Next XDR Expert

Kaspersky Deployment Toolkit deploys Kaspersky Next XDR Expert by using the configuration file. KDT automatically deploys the Kubernetes cluster within which the Kaspersky Next XDR Expert components and other infrastructure components are installed.

If you need to install multiple Kubernetes clusters with Kaspersky Next XDR Expert instances, you can use the required number of contexts.

To install Kaspersky Next XDR Expert:

  1. Unpack the downloaded distribution package with KDT on the administrator host.
  2. Read the End User License Agreement (EULA) of KDT located in the distribution package with the Kaspersky Next XDR Expert components.

    When you start using KDT, you accept the terms of the EULA of KDT.

    You can read the EULA of KDT after the deployment of Kaspersky Next XDR Expert. The file is located in the /home/kdt/ directory of the user who runs the deployment of Kaspersky Next XDR Expert.

  3. On the administrator host, run the following commands to start deployment of Kaspersky Next XDR Expert. Specify the path to the the transport archive with the Kaspersky Next XDR Expert components and the path to the configuration file that you filled out earlier.

    chmod +x kdt

    ./kdt apply -k <path_to_transport_archive> -i <path_to_configuration_file>

    You can install Kaspersky Next XDR Expert without prompting to read the terms of the EULA and the Privacy Policy of OSMP if you use the --accept-eula flag. You can read the EULA and the Privacy Policy of OSMP before the deployment of Kaspersky Next XDR Expert. The files are located in the distribution package with the Kaspersky Next XDR Expert components.

    If you want to read and accept the terms of the EULA and the Privacy Policy during the deployment, do not use the --accept-eula flag.

  4. If you do not use the --accept-eula flag in the previous step, read the EULA and the Privacy Policy of OSMP. The text is displayed in the command line window. Press the space bar to view the next text segment. Then, when prompted, enter the following values:
    1. Enter y if you understand and accept the terms of the EULA.

      Enter n if you do not accept the terms of the EULA. To use Kaspersky Next XDR Expert, you must accept the terms of the EULA.

    2. Enter y if you understand and accept the terms of the Privacy Policy, and you agree that your data will be handled and transmitted (including to third countries) as described in the Privacy Policy.

      Enter n if you do not accept the terms of the Privacy Policy.

      To use Kaspersky Next XDR Expert, you must accept the terms of the EULA and the Privacy Policy.

    After you accept the EULA and the Privacy Policy, KDT deploys the Kaspersky Next XDR Expert components within the Kubernetes cluster on the target hosts.

    During the Kaspersky Next XDR Expert deployment, a new user is created on the primary Administration Server. To start configuring OSMP Console, this user is assigned the following roles: the XDR role of the Main administrator in the Root tenant and the Kaspersky Security Center role of the Main administrator.

  5. View the installation logs of the Bootstrap component in the directory with the KDT utility and obtain diagnostic information about Kaspersky Next XDR Expert components, if needed.
  6. Sign in to the OSMP Console and to the KUMA Console.

    The default OSMP Console address is https://console.<smp_domain>:443.

    The default KUMA Console address is https://kuma.<smp_domain>:7220.

Page top
[Topic 249213]

Single node deployment: Specifying the installation parameters

Expand all | Collapse all

If you want to deploy Kaspersky Next XDR Expert on a single node, fill out the installation parameters of the configuration file that are required both for the distributed and single node deployment, as well as define the following specific parameters: type, lowResources, vault_replicas, vault_ha_mode, vault_standalone, and defaultClassReplicaCount.

The template of the configuration file for the single node deployment is located in the distribution package with the Kaspersky Next XDR Expert components. You can fill out the configuration file template manually; or use the Configuration wizard to specify the installation parameters that are required for the Kaspersky Next XDR Expert deployment, and then generate the configuration file.

For correct work of KDT with the configuration file, enter an empty line at the end of the file.

The nodes section of the configuration file contains the target host parameters that are listed in the table below.

Installation parameters of the nodes section

Parameter name

Required

Description

Possible values

desc

Yes

The name of the node.

String value

type

Yes

The node type.

For the target host, set the type parameter to primary-worker to enable the single node deployment. In this case, the target host will act as the primary and worker nodes.

primary

worker

primary-worker

host

Yes

The IP address of the node. All nodes must be included in the same subnet.

IP address

kind

No

The node type that specifies the Kaspersky Next XDR Expert component that will be installed on this node. If the kind parameter of the node is set to admsrv, Administration Server will be installed on this node. If you want to install a DBMS on the node inside the cluster, set the kind parameter to db for the corresponding node. For other nodes, you can leave this parameter empty.

Do not specify the kind parameter when you deploy Kaspersky Next XDR Expert on a single node.

admsrv or db

user

Yes

The username of the user account created on the target host and used for connection to the node by KDT.

String value

key

Yes

The path to the private part of the SSH key located on the administrator host and used for connection to the node by KDT.

String value

The parameters section of the configuration file contains the parameters listed in the table below.

Installation parameters of the parameters section

Parameter name

Required

Description

Possible values

psql_dsn

Yes

The connection string for accessing the DBMS that is installed and configured on a separate server. 

Specify this parameter as follows: psql_dsn=postgres://<dbms_username>:<password>@<fqdn>:<port>.

dbms_username—The user name of a privileged internal DBMS account. This account is granted permissions to create databases and other DBMS accounts. By using this privileged DBMS account, the databases and other DBMS accounts required for the Kaspersky Next XDR Expert components will be created during the deployment. 

password—The password of the privileged internal DBMS account.

fqdn:port—The FQDN and connection port of a separate server on which the DBMS is installed.

If the psql_dsn parameter is set, the Kaspersky Next XDR Expert components use the DBMS located at the specified FQDN. Otherwise, the Kaspersky Next XDR Expert components use the DBMS inside the cluster.

We recommend installing a DBMS on a separate server outside the cluster.
After you deploy Kaspersky Next XDR Expert, changing the DBMS installed inside the cluster to a DBMS installed on a separate server is not available.

String value

nwc-language

Yes

The language of the OSMP Console interface specified by default. After installation, you can change the OSMP Console language.

enUS or ruRu

ipaddress

Yes

The reserved static IP address of the Kubernetes cluster gateway. The gateway must be included in the same subnet as all cluster nodes.

If you install the DBMS on a separate server, the gateway IP address must contain the subnet mask /32.

If you install the DBMS inside the cluster, set the gateway IP address to an IP range in the format 0.0.0.0-0.0.0.0, where the first IP address of the range is the gateway IP address itself and the second IP address of the range is the DBMS IP address.

IP address

ssh_pk

Yes

The path to the private part of the SSH key located on the administrator host and used for connection to the node by KDT.

String value

sshKey

Yes

The path to the private part of the SSH key located on the administrator host and used for connection to the nodes with the KUMA services (collectors, correlators and storages).

String value

kscpassword, adminPassword

Yes

The kscpassword and adminPassword parameters specify the password of the same Kaspersky Next XDR Expert user account that will be created by KDT during the installation. The default username of this account is "admin".

The Main administrator role is assigned to this user account.

The kscpassword and adminPassword parameter values must match.

The adminPassword parameter is used for uploading the KUMA license and out of the box resources.

The password must comply with the following rules:

  • The user password cannot have less than 8 or more than 16 characters.
  • The password must contain characters from at least three of the groups listed below:
    • Uppercase letters (A–Z)
    • Lowercase letters (a–z)
    • Numbers (0–9)
    • Special characters (@ # $ % ^ & * - _ ! + = [ ] { } | : ' , . ? / \ ` ~ " ( ) ;)

String value

lowResources

No

The parameter that indicates that Kaspersky Next XDR Expert is installed on the target host with limited computing resources.

Set the lowResources parameter to true to Kaspersky Next XDR Expert components will require less memory and CPU resources. Also, if you enable this parameter, 4 GB of free disk space will be allocated to install KUMA Core on the target host.

true or false

vault_replicas

No

The number of replicas of the secret storage in the Kubernetes cluster.

Set the vault_replicas parameter to 1 to use one secret storage replica.

Integer value

vault_ha_mode

No

The parameter that indicates whether to run the secret storage in the High Availability (HA) mode.

Set the vault_ha_mode parameter to false to disable the distributed deployment of Kaspersky Next XDR Expert.

true or false

vault_standalone

No

The parameter that indicates whether to run the secret storage in the standalone mode.

Set the vault_standalone parameter value to true.

true or false

coreDiskRequest

Yes

The parameter that specifies the amount of disk space for the operation of KUMA Core. This parameter is used only if the lowResources parameter is set to false. If the lowResources parameter is set to true, the coreDiskRequest parameter is ignored and 4 GB of the disk space for the operation of KUMA Core is allocated. If you do not specify the coreDiskRequest parameter and the lowResources parameter is set to false, the default amount of disk space for the operation of KUMA Core is allocated. The default amount of disk space is 512 GB.

String value

inventory

Yes

The path to the KUMA inventory file located on the administrator host. The inventory file contains installation parameters for deployment of the KUMA services that are not included in the Kubernetes cluster.

String value

hostInventory

No

The path to the additional KUMA inventory file located on the administrator host. This file contains the installation parameters used to partially add or remove hosts with the KUMA services.

If you perform an initial deployment of Kaspersky Next XDR Expert or you do not need to partially add or remove hosts with the KUMA services, set this parameter to /dev/null.

String value

license

Yes

The path to the license key of KUMA.

String value

smp_domain

Yes

The domain name that is used in the addresses of the public Kaspersky Next XDR Expert services.

String value

pki_domain

Yes

The domain name for which a self-signed or custom certificate is to be generated. The pki_domain and smp_domain parameter values must match.

String value

iam-nwc_host, flow_host, hydra_host, login_host, admsrv_fqdn, console_fqdn, api_fqdn, kuma_fqdn, psql_fqdn, monitoring_fqdn, coreIngressHost, gateway_host, hydra_fqdn, IAMHydraServerPublicExternal

Yes

The addresses of the Kaspersky Next XDR Expert services. These addresses contain the domain name, which must match the smp_domain parameter value.

String value

pki_fqdn_list

Yes

The list of addresses of the public Kaspersky Next XDR Expert services for which a self-signed or custom certificate is to be generated. These addresses contain the domain name, which must match the smp_domain parameter value.

String value

intermediate_bundle

No

The path to the custom intermediate certificate used to work with public Kaspersky Next XDR Expert services.

String value

intermediate_enabled

No

The parameter that indicates whether to use the custom intermediate certificate instead of the self-signed certificates for the public Kaspersky Next XDR Expert services.

true or false

admsrv_bundle, api_bundle, console_bundle, psql_bundle

No

The paths to the custom leaf certificates used to work with the corresponding public Kaspersky Next XDR Expert services: admsrv.<smp_domain>, api.<smp_domain>, console.<smp_domain>, psql.<smp_domain>. Specify the psql_bundle parameter if you installed the DBMS inside the Kubernetes cluster on the DBMS node.

If you want to specify the leaf custom certificates, set the intermediate_enabled parameter to false and do not specify the intermediate_bundle parameter.

String value

KUMAUIURL

Yes

The address of KUMA Console. This address contains the domain name, which must match the smp_domain parameter value.

String value

webConsoleURL

Yes

The address of OSMP Console. This address contains the domain name, which must match the smp_domain parameter value.

String value

encrypt_secret, sign_secret

Yes

The names of the secret files that are stored in the Kubernetes cluster. These names contain the domain name, which must match the smp_domain parameter value.

String value

ksc_state_size

Yes

The amount of free disk space allocated to store the Administration Server data (updates, installation packages, and other internal service data).

String value

defaultClassReplicaCount

No

The number of disk volumes that are used to store the service data of Kaspersky Next XDR Expert components and KDT. The default value is 3.

Set the defaultClassReplicaCount parameter value to 1.

Integer value

kdtStateSize

No

The amount of free disk space allocated to store the internal service KDT data. The default value is 5Gi.

String value

prometheus_size

Yes

The amount of free disk space allocated to store metrics. The minimum recommend value is 5 GB.

String value

loki_size

Yes

The amount of free disk space allocated to store OSMP logs. The minimum recommend value is 20 GB.

String value

adminLogin

Yes

The adminLogin parameter specifies the username of the Kaspersky Next XDR Expert user account that will be created by KDT during the installation. This parameter is used for uploading of the KUMA resources.

The adminLogin and kumaLogin parameter values must match.

The default parameter value is admin. Do not change the parameter value.

String value

psql_tls_off

No

The parameter that indicates whether to encrypt the traffic between the Kaspersky Next XDR Expert components and the DBMS by using the TLS protocol.

Set the psql_tls_off parameter to true if the DBMS is installed inside the cluster.

true or false

psql_trusted_cas

No

The path to the PEM file that can contain the TLS certificate of the DBMS server or a root certificate from which the TLS server certificate can be issued.

Specify the psql_trusted_cas parameter if the DBMS is installed and configured on a separate server.

String value

psql_client_certificate

No

The path to the PEM file that contains a certificate and a private key of the Kaspersky Next XDR Expert component. This certificate is used to establish the TLS connection between the Kaspersky Next XDR Expert components and the DBMS.

Specify the psql_client_certificate parameter if the DBMS is installed and configured on a separate server.

String value

proxy_enabled

No

The parameter that indicates whether to use the proxy server to connect the Kaspersky Next XDR Expert components to the internet. If the host on which Kaspersky Next XDR Expert is installed has internet access, you can also provide internet access for operation of Kaspersky Next XDR Expert components (for example, Administration Server) and for specific integrations, both Kaspersky and third-party. To establish the proxy connection, you must also specify the proxy server parameters in the Administration Server properties.

true or false

proxy_addresses

No

The IP address of the proxy server. If the proxy server uses multiple IP addresses, specify these addresses separated by a space (for example, "0.0.0.0 0.0.0.1 0.0.0.2").

String value

proxy_port

No

The number of the port through which the proxy connection will be established.

String value

tracelevel

No

The trace level. The default value is 0.

Integer value (0–5)

psql_ns, psql_instancekumaUrlkumaLogin

Yes

The parameters for internal use. Do not change the parameter value.

String value

Sample of the configuration file for the single node deployment of Kaspersky Next XDR Expert

schemaType: ParameterSet

schemaVersion: 1.0.1

namespace: ""

name: bootstrap

project: xdr

nodes:

- desc: cdt-1

type: primary-worker

host: 1.1.1.1

proxy:

access:

ssh:

user: root

key: /root/.ssh/id_rsa

parameters:

- name: nwc-language

source:

value: "enUS"

- name: ipaddress

source:

value: 1.1.1.2-1.1.1.3

- name: ssh_pk

source:

path: /root/.ssh/id_rsa

- name: sshKey

source:

path: /root/.ssh/id_rsa

- name: kscpassword

source:

value: "password"

- name: adminPassword

source:

value: "password"

- name: lowResources

source:

value: "true"

- name: defaultClassReplicaCount

source:

value: "1"

- name: vault_replicas

source:

value: "1"

- name: vault_ha_mode

source:

value: "false"

- name: vault_standalone

source:

value: "true"

- name: inventory

source:

value: "/root/osmp/inventory.yaml"

- name: hostInventory

source:

value: "/dev/null"

- name: license

source:

value: "/root/osmp/license.key"

- name: smp_domain

source:

value: "smp.local"

- name: pki_domain

source:

value: "smp.local"

- name: iam-nwc_host

source:

value: "console.smp.local"

- name: flow_host

source:

value: "console.smp.local"

- name: hydra_host

source:

value: "console.smp.local"

- name: login_host

source:

value: "console.smp.local"

- name: admsrv_fqdn

source:

value: "admsrv.smp.local"

- name: console_fqdn

source:

value: "console.smp.local"

- name: api_fqdn

source:

value: "api.smp.local"

- name: kuma_fqdn

source:

value: "kuma.smp.local"

- name: psql_fqdn

source:

value: "psql.smp.local"

- name: monitoring_fqdn

source:

value: "monitoring.smp.local"

- name: coreIngressHost

source:

value: kuma.smp.local

- name: gateway_host

source:

value: console.smp.local

- name: hydra_fqdn

source:

value: console.smp.local

- name: KUMAUIURL

source:

value: https://kuma.smp.local:7220

- name: webConsoleURL

source:

value: https://console.smp.local:443

- name: IAMHydraServerPublicExternal

source:

value: "https://console.smp.local:443"

- name: pki_fqdn_list

source:

value: "admsrv.smp.local api.smp.local console.smp.local kuma.smp.local psql.smp.local monitoring.smp.local"

- name: encrypt_secret

source:

value: "ksc.encrypt.smp.local"

- name: sign_secret

source:

value: "iam.sign.smp.local"

- name: ksc_state_size

source:

value: "20Gi"

- name: ksc_backup_size

source:

value: "10Gi"

- name: prometheus_size

source:

value: "10GB"

- name: loki_size

source:

value: "20Gi"

- name: kumaUrl

source:

value: "http://core.kuma.svc.cluster.local:7220"

- name: kumaLogin

source:

value: "admin"

- name: adminLogin

source:

value: "admin"

- name: intermediate_bundle

source:

path: "./bundle.pem"

- name: intermediate_enabled

source:

value: "true"

- name: admsrv_bundle

source:

path: "/dev/null"

- name: api_bundle

source:

path: "/dev/null"

- name: console_bundle

source:

path: "/dev/null"

- name: psql_bundle

source:

path: "/dev/null"

- name: tracelevel

source:

value: "0"

- name: proxy_enabled

source:

value: "true"

- name: proxy_addresses

source:

value: "0.0.0.0 0.0.0.1 0.0.0.2"

- name: proxy_port

source:

value: "8080"

Page top
[Topic 271992]

Single node deployment: Installing Kaspersky Next XDR Expert

If necessary, you can perform the single node deployment of Kaspersky Next XDR Expert so that the solution requires fewer computing resources (for example, for demonstration purposes).

In this configuration, the administrator host is used to install and manage the Kubernetes cluster and Kaspersky Next XDR Expert, as with distributed deployment. KDT is launched from the administrator host.

One target host, which acts as the primary and worker nodes, manages the Kubernetes cluster, stores metadata, and performs the workload of the Kaspersky Next XDR Expert components. The Kubernetes cluster and Kaspersky Next XDR Expert components are installed on this target host. Only the target host is included in the Kubernetes cluster (the primary worker node of the cluster).

To perform the single node deployment of Kaspersky Next XDR Expert:

  1. Download the distribution package that has the Kaspersky Next XDR Expert components.
  2. Install a database management system.

    Skip this step if you want to install the DBMS inside the cluster. KDT will install the DBMS during the Kaspersky Next XDR Expert deployment. In this case, the Kaspersky Next XDR Expert components and the DBMS will use one target host.

    Alternatively, you can install the DBMS on a separate server outside the cluster.

  3. Prepare the administrator and target hosts, as with distributed deployment.

    Make sure that the hardware and software on the target host meet the requirements for the single node deployment.

    For the target host that acts as a primary worker node, perform all preparatory steps necessary for both primary and worker nodes.

  4. Prepare the KUMA target hosts for installation of the KUMA services.
  5. Prepare the KUMA inventory file.
  6. Fill out the configuration file manually or by using the Configuration wizard.

    The deployment method (distributed deployment or single node deployment) is determined by the installation parameters. The following installation parameters are specific to the single node deployment: type, lowResources, vault_replicas, vault_ha_mode, vault_standalone, defaultClassReplicaCount.

  7. Install Kaspersky Next XDR Expert by using KDT.

The Kubernetes cluster and Kaspersky Next XDR Expert components are deployed on the primary worker node, and the KUMA services are installed.

Page top
[Topic 271318]

Configuration wizard for the Kaspersky Next XDR Expert deployment

For the distributed and single node Kaspersky Next XDR Expert deployment, you have to prepare a configuration file that contains the installation parameters of the Kaspersky Next XDR Expert components. The Configuration wizard allows you to specify the installation parameters that are required to deploy Kaspersky Next XDR Expert, and then generate the resulting configuration file.

Prerequisites

Before specifying the installation parameters by using the Configuration wizard, you must do the following:

Process

To specify the installation parameters by using the Configuration wizard:

  1. On the administrator host where the KDT utility is located, run the Configuration wizard by using the following command:

    ./kdt wizard -k <path_to_transport_archive> -o <path_to_configuration_file>

    where:

    • <path_to_transport_archive> is the path to the transport archive.
    • <path_to_configuration_file> is the path where you want to save the configuration file and the configuration file name.

    The Configuration wizard prompts you to specify the installation parameters. The list of the installation parameters that are specific for the distributed and single node deployment differs.

    If you do not have the Write permissions on the specified directory or a file with the same name is located in this directory, an error occurs and the wizard terminates.

  2. Enter the IPv4 address of a primary node (the host parameter of the configuration file).

    If you want to perform the single node deployment, this node will act as a primary-worker node.

  3. Enter the username of the user account used for connection to the primary node by KDT (the user parameter of the configuration file).
  4. Enter the path to the private part of the SSH key located on the administrator host and that is used for connection to the primary node by KDT (the key parameter of the configuration file).

    The default value is /root/.ssh/id_rsa.

  5. Enter the number of worker nodes.

    Possible values:

    This step defines the option of deploying Kaspersky Next XDR Expert. If you want to perform single node deployment, the following parameters specific for this deployment option will take the default values:

    • typeprimary-worker
    • lowResourcestrue
    • vault_replicas1
    • vault_ha_modefalse
    • vault_standalonetrue
    • defaultClassReplicaCount1
  6. For each worker node, enter the IPv4 address (the host parameter of the configuration file).

    Note that the primary and worker nodes must be included in the same subnet.

    The kind parameter of the first worker node is set to admsrv by default. That means that Administration Server will be installed on the first worker node.

  7. For each worker node, enter the username used for connection to the worker node by KDT (the user parameter of the configuration file).
  8. For each worker node, enter the path to the private part of the SSH key used for connection to the worker node by KDT (the key parameter of the configuration file).

    The default value is /root/.ssh/id_rsa.

  9. Enter the connection string for accessing the DBMS that is installed and configured on a separate server (the psql_dsn parameter of the configuration file).

    Specify this parameter as follows: postgres://<dbms_username>:<password>@<fqdn>:<port>.

  10. Enter the reserved static IP address of the Kubernetes cluster gateway (the ipaddress parameter of the configuration file).

    The gateway must be included in the same subnet as all cluster nodes. The gateway IP address must contain the subnet mask /32.

  11. Enter the username of the Kaspersky Next XDR Expert user account that will be created by KDT during the installation (the adminLogin and kumaLogin parameters of the configuration file).

    The default username of this account is "admin." The Main administrator role is assigned to this user account.

  12. Enter the password of the Kaspersky Next XDR Expert user account that will be created by KDT during the installation (the kscpassword and adminPassword parameters of the configuration file).
  13. Enter the path to the KUMA inventory file located on the administrator host (the inventory parameter of the configuration file).

    The KUMA inventory file contains the installation parameters for deployment of the KUMA services that are not included in the Kubernetes cluster.

  14. Enter the path to the private part of the SSH key located on the administrator host and used for connection to the nodes with the KUMA services (the sshkey parameter of the configuration file).
  15. Enter the path to the LICENSE file of KUMA (the license parameter of the configuration file).
  16. Enter the domain name that is used in the addresses of the public Kaspersky Next XDR Expert services (the smp_domain parameter of the configuration file).
  17. Enter the path to the custom certificates used to work with the public Kaspersky Next XDR Expert services (the intermediate_bundle parameter of the configuration file).

    If you want to use self-signed certificates, press Enter to skip this step.

  18. Check the specified parameters that are displayed in the numbered list.

    To edit the parameter, enter the parameter number, and then specify a new parameter value. Otherwise, press Enter to continue.

  19. Press Y to save a new configuration file with the specified parameters or N to stop the Configuration wizard without saving.

The configuration file with the specified parameters is saved in the YAML format.

Other installation parameters are included in the configuration file, with default values. You can edit the configuration file manually before the deployment of Kaspersky Next XDR Expert.

Page top
[Topic 271043]

Configuring internet access for the target hosts

If your organization's infrastructure uses the proxy server to access the internet, as well as you need to connect the target hosts to the internet, you must add the IP address of each target host to the no_proxy variable in the /etc/environment file before the Kaspersky Next XDR Expert deployment. This allows you to establish a direct connection of the target hosts to the internet and correctly deploy Kaspersky Next XDR Expert.

To configure internet access for the target hosts:

  1. On the target host, open the /etc/environment file by using a text editor. For example, the following command opens the file by using the GNU nano text editor:

    sudo nano /etc/environment

  2. In the /etc/environment file, add the IP address of the target host to the no_proxy variable separated by a comma without a space.

    For example, the no_proxy variable can be initially specified as follows:

    no_proxy=localhost,127.0.0.1

    You can add the IP address of the target host (192.168.0.1) to the no_proxy variable:

    no_proxy=localhost,127.0.0.1,192.168.0.1

    Alternatively, you can specify the subnet that includes the target hosts (in CIDR notation):

    no_proxy=localhost,127.0.0.1,192.168.0.0/24

  3. Save the /etc/environment file.

After you add the IP addresses in the /etc/environment file to each target host, you can continue preparing of the target hosts and further Kaspersky Next XDR Expert deployment.

Page top
[Topic 275599]

Installation requirements for the KUMA services

Before installation of the KUMA services, make sure the following conditions are met:

 

Astra Linux

Python version

3.6 or later

SELinux module

Disabled

Package manager

pip3

Basic packages

  • python3-apt
  • curl
  • libcurl4

The packages can be installed using the following command:

apt install python3-apt curl libcurl4

Dependent packages

  • netaddr
  • python3-cffi-backend

    The packages can be installed by using the following command:

apt install python3-netaddr python3-cffi-backend

If you are planning to query Oracle DB databases from KUMA, you must install the libaio1 Astra Linux package.

User permissions level required to install the application

To assign the required permissions to the user account used for installing the application, run the following command:

sudo pdpl-user -i 63 <user name under which the application is being installed>

Page top
[Topic 265300]

Synchronizing time on machines

To configure time synchronization on machines:

  1. Run the following command to install chrony:

    sudo apt install chrony

  2. Configure the system time to synchronize with the NTP server:
    1. Make sure the virtual machine has internet access.

      If access is available, go to step b.

      If internet access is not available, edit the /etc/chrony.conf file. Replace 2.pool.ntp.org with the name or IP address of your organization's internal NTP server.

    2. Start the system time synchronization service by executing the following command:

      sudo systemctl enable --now chronyd

    3. Wait a few seconds, and then run the following command:

      sudo timedatectl | grep 'System clock synchronized'

      If the system time is synchronized correctly, the output will contains the line System clock synchronized: yes.

Synchronization is configured.

Page top
[Topic 265841]

Installing KUMA services

Services are the main components of KUMA that help the system to manage events. Services allow you to receive events from event sources and subsequently bring them to a common form that is convenient for finding correlation, as well as for storage and manual analysis.

Service types:

  • Storages are used to save events.
  • Collectors are used to receive events and convert them to the KUMA format.
  • Correlators are used to analyze events and search for defined patterns.
  • Agents are used to receive events on remote devices and forward them to the KUMA collectors.

You must install the KUMA services only after you deploy Kaspersky Next XDR Expert. During the Kaspersky Next XDR Expert deployment, the required infrastructure is prepared: the service directories are created on the prepared hosts, and the files that are required for the service installation are added to these directories. We recommend installing services in the following order: storage, collectors, correlators, and agents.

To install and configure the KUMA services:

  1. Sign in to the KUMA console.

    You can use one of the following methods:

    • In the main menu of OSMP Console, go to SettingsKUMA.
    • In your browser, go to https://kuma.<smp_domain>:7220.
  2. In the KUMA console, create a resource set for each KUMA service (storages, collectors, and correlators) that you want to install on the prepared hosts in the network infrastructure.
  3. Create services for storages, collectors, and correlators in KUMA Console.
  4. Obtain the service identifiers to bind the created resource sets and the KUMA services:
    1. In the KUMA Console main menu, go to ResourcesActive services.
    2. Select the required KUMA service, and then click the Copy ID button.
  5. On the prepared hosts in the network infrastructure, run the corresponding commands to install the KUMA services. Use the service identifiers that were obtained earlier:
    • Installation command for the storage:

      sudo /opt/kaspersky/kuma/kuma storage --core https://<KUMA Core server FQDN>:7210 --id <service ID copied from the KUMA Console> --install

    • Installation command for the collector:

      sudo /opt/kaspersky/kuma/kuma collector --core https://<KUMA Core server FQDN>:7210 --id <service ID copied from the KUMA Console> --api.port <port used for communication with the collector>

    • Installation command for the correlator:

      sudo /opt/kaspersky/kuma/kuma correlator --core https://<KUMA Core server FQDN>:7210 --id <service ID copied from the KUMA Console> --api.port <port used for communication with the correlator> --install

    By default, the FQDN of the KUMA Core is kuma.<smp_domain>.

    The port that is used for connection to KUMA Core cannot be changed. By default, port 7210 is used.

    Open ports that correspond to the installed collector and correlator on the server (TCP 7221 and other ports used for service installation as the --api.port <port> parameter values).

  6. During the installation of the KUMA services, read the End User License Agreement (EULA) of KUMA. The text is displayed in the command line window. Press the space bar to view the next text segment. Then, when prompted, enter the following values:
    • Enter y if you understand and accept the terms of the EULA.
    • Enter n if you do not accept the terms of the EULA. To use the KUMA services, you must accept the terms of the EULA.

    You can read the EULA of KUMA after the installation of the KUMA services in one of the following ways:

    • On hosts, it is included in the kuma_utils group in the KUMA inventory file: open the LICENSE file located in the /opt/kaspersky/kuma/utils directory.
    • On hosts, it is included in other groups (kuma_storage, kuma_collector, or kuma_correlator) in the KUMA inventory file: open the LICENSE file located in the /opt/kaspersky/kuma directory.
    • Run the following command:

      /opt/kaspersky/kuma/kuma license --show

    After you accept the EULA, the KUMA services are installed on the prepared machines in the network infrastructure.

  7. If necessary, verify that the collector and correlator are ready to receive events.
  8. If necessary, install agents in the KUMA network infrastructure.

    The files required for the agent installation are located in the /opt/kaspersky/kuma/utils directory.

The KUMA services required for the function of Kaspersky Next XDR Expert are installed.

Page top
[Topic 265478]

Deployment of multiple Kubernetes clusters and Kaspersky Next XDR Expert instances

KDT allows you to deploy multiple Kubernetes clusters with Kaspersky Next XDR Expert instances and switch between them by using contexts. Context is a set of access parameters that define the Kubernetes cluster that the user can select to interact with. The context also includes data for connecting to the cluster by using KDT.

Prerequisites

Before creating contexts and installing Kubernetes clusters with Kaspersky Next XDR Expert instances, you must do the following:

  1. Prepare the administrator and target hosts.

    For the installation of multiple clusters and Kaspersky Next XDR Expert instances, you need to prepare one administration host for all clusters and separate sets of target hosts for each of the clusters. Kubernetes components should not be installed on the target hosts.

  2. Prepare the hosts for installation of the KUMA services.

    For installation of the KUMA services, you need to prepare separate sets of hosts for each Kaspersky Next XDR Expert instance.

  3. Prepare the KUMA inventory file.

    For installation of the KUMA services, you need to prepare separate inventory files for each Kaspersky Next XDR Expert instance.

  4. Prepare the configuration file.

    For installation of multiple clusters and Kaspersky Next XDR Expert instances, you need to prepare configuration files for each Kaspersky Next XDR Expert instance. In these configuration files, specify the corresponding administration and target hosts, and other parameters specific to a particular cluster and Kaspersky Next XDR Expert instance.

Process

To create a context with the Kubernetes cluster and Kaspersky Next XDR Expert instance:

  1. On the administrator host where the KDT utility is located, run the following command and specify the context name:

    ./kdt ctx <context_name> --create

    The context with the specified name is created.

  2. Install the Kubernetes cluster and Kaspersky Next XDR Expert.

The cluster with the Kaspersky Next XDR Expert instance is deployed in the context. The creation of the context is finished.

You can repeat this procedure to create the required number of contexts with installed clusters and Kaspersky Next XDR Expert instances.

You must deploy the Kubernetes cluster and the Kaspersky Next XDR Expert instance after you create the context to finish the context creation. If you do not perform the deployment in the context, and then create another context, the first context will be removed.

You can view the list of created contexts by using the following command:

./kdt ctx

If you want to switch to the required context, run the following command and specify the context name:

./kdt ctx <context_name>

After you select the context, KDT connects to the corresponding Kubernetes cluster. Now, you can work with this cluster and the Kaspersky Next XDR Expert instance. KDT commands are applied to the selected cluster.

When you remove the Kaspersky Next XDR Expert components installed in the Kubernetes cluster and the cluster itself by using KDT, the corresponding contexts are also removed. Other contexts and their clusters with Kaspersky Next XDR Expert instances are not removed.

Page top
[Topic 269993]

Signing in to Kaspersky Next XDR Expert

To sign in to Kaspersky Next XDR Expert, you must know the web address of Open Single Management Platform Console. In your browser, JavaScript must be enabled.

To sign in to Open Single Management Platform Console:

  1. In your browser, go to <Open Single Management Platform Console web address>.

    The sign-in page is displayed.

  2. Do one of the following:
    • To sign in to Open Single Management Platform Console with a domain user account, enter the user name and password of the domain user.

      You can enter the user name of the domain user in one of the following formats:

      • Username@dns.domain
      • NTDOMAIN\Username

      Before you sign in with a domain user account, poll the domain controller to obtain the list of domain users.

    • Enter the user name and password of the internal user.
    • If one or more virtual Servers are created on the Server and you want to sign in to a virtual Server:
      1. Click Show virtual Server options.
      2. Type the virtual Server name that you specified while creating the virtual Server.
      3. Enter the user name and password of the internal or domain user who has rights on the virtual Server.
  3. Click the Sign in button.

After sign-in, the dashboard is displayed, and it contains the language and theme that you used the last time you signed in.

Kaspersky Next XDR Expert allows you to work with Open Single Management Platform Console and KUMA Console interfaces.

If you sign in to one of the consoles, and then open the other console on a different tab of the same browser window, you are signed in to the other console without having to re-enter the credentials. In this case, when you sign out of one console, the session also ends for the other console.

If you use different browser windows or different devices to sign in to Open Single Management Platform Console and KUMA Console, you have to re-enter the credentials. In this case, when you sign out of one console on the browser window or device where it is open, the session continues on the window or device where the other console is open.

To sign out of Open Single Management Platform Console,

In the main menu, go to your account settings, and then select Sign out.

Open Single Management Platform Console is closed and the sign-in page is displayed.

Page top
[Topic 249152]