Kaspersky Next XDR Expert
- Kaspersky Next XDR Expert
- Quick links
- What's new
- About Kaspersky Next XDR Expert
- Architecture of Open Single Management Platform
- OSMP Console interface
- Licensing
- About data provision
- Quick start guide
- Deployment of Kaspersky Next XDR Expert
- Hardening Guide
- Deployment schemes
- Ports used by Kaspersky Next XDR Expert
- Preparation work and deployment
- Multi-node deployment: Preparing the administrator and target hosts
- Single-node deployment: Preparing the administrator and target hosts
- Preparing the hosts for installation of the KUMA services
- Installing a database management system
- Configuring the PostgreSQL or Postgres Pro server for working with Open Single Management Platform
- Preparing the KUMA inventory file
- Multi-node deployment: Specifying the installation parameters
- Single-node deployment: Specifying the installation parameters
- Specifying the installation parameters by using the Configuration wizard
- Installing Kaspersky Next XDR Expert
- Configuring internet access for the target hosts
- Synchronizing time on machines
- Installing KUMA services
- Deployment of multiple Kubernetes clusters and Kaspersky Next XDR Expert instances
- Pre-check of infrastructure readiness for deployment
- Signing in to Kaspersky Next XDR Expert
- Kaspersky Next XDR Expert maintenance
- Upgrading Kaspersky Next XDR Expert from version 1.2 to 1.3
- Updating Kaspersky Next XDR Expert components
- Changing the Kaspersky Next XDR Expert parameters without reinstalling
- Adding and deleting nodes of the Kubernetes cluster
- Versioning the configuration file
- Uninstalling Kaspersky Next XDR Expert
- Manual uninstalling of Kaspersky Next XDR Expert components
- Reinstalling Kaspersky Next XDR Expert after a failed installation
- Reinstalling Kaspersky Next XDR Expert components
- Stopping the Kubernetes cluster nodes
- Using certificates for public Kaspersky Next XDR Expert services
- Calculation and changing of disk space for storing Administration Server data
- Rotation of secrets
- Adding hosts for installing the additional KUMA services
- Replacing a host that uses KUMA storage
- Demonstration deployment of Kaspersky Next XDR Expert
- Migration to Kaspersky Next XDR Expert
- Integration with other solutions
- Threat detection
- Working with alerts
- About alerts
- Alert data model
- Viewing the alert table
- Viewing alert details
- Assigning alerts to analysts
- Changing an alert status
- Creating alerts manually
- Linking alerts to incidents
- Unlinking alerts from incidents
- Linking events to alerts
- Unlinking events from alerts
- Working with alerts on the investigation graph
- Managing aggregation rules
- Working with incidents
- About incidents
- Incident data model
- Creating incidents
- Creating child incidents
- Viewing the incident table
- Viewing incident details
- Assigning incidents to analysts
- Changing an incident status
- Changing an incident priority
- Changing an incident type
- Merging incidents
- Investigation graph
- Segmentation rules
- Copying segmentation rules to another tenant
- Managing incident types
- Managing incident workflows
- Configuring the retention period of alerts and incidents
- Viewing asset details
- Working with alerts
- Threat hunting
- Threat response
- Response actions
- Terminating processes
- Moving devices to another administration group
- Running a malware scan
- Viewing the result of the malware scan
- Updating databases
- Moving files to quarantine
- Changing authorization status of devices
- Viewing information about KASAP users and changing learning groups
- Responding through Active Directory
- Responding through KATA/KEDR
- Responding through UserGate
- Responding through Ideco NGFW
- Responding through Ideco UTM
- Responding through Redmine
- Responding through Check Point NGFW
- Responding through Sophos Firewall
- Responding through Continent 4
- Responding through SKDPU NT
- Responding through FortiGate
- Blocking IP addresses through Kaspersky NGFW
- Viewing response history from alert or incident details
- Playbooks
- Viewing the playbooks table
- Creating playbooks
- Editing playbooks
- Customizing playbooks
- Viewing playbook properties
- Terminating playbooks
- Deleting playbooks
- Launching playbooks and response actions
- Configuring manual approval of response actions
- Approving playbooks or response actions
- Enrichment from playbook
- Viewing response history
- Predefined playbooks
- Playbook trigger
- Playbook algorithm
- Editing incidents by using playbooks
- Editing alerts by using playbooks
- Response actions
- REST API
- Managing Kaspersky Unified Monitoring and Analysis Platform
- Program architecture
- Administrator's guide
- Logging in to the KUMA Console
- KUMA services
- Services tools
- Service resource sets
- Creating a storage
- Creating a correlator
- Creating an event router
- Creating a collector
- Creating an agent
- Configuring event sources
- Configuring receipt of Auditd events
- Configuring receipt of KATA/EDR events
- Configuring Open Single Management Platform for export of events to the KUMA SIEM-system
- Configuring receiving Open Single Management Platform event from MS SQL
- Creating an account in the MS SQL database
- Configuring the SQL Server Browser service
- Creating a secret in KUMA
- Configuring a connector
- Configuring the KUMA Collector for receiving Kaspersky Security Center events from an MS SQL database
- Installing the KUMA Collector for receiving Kaspersky Security Center events from the MS SQL database
- Configuring receipt of events from Windows devices using KUMA Agent (WEC)
- Configuring audit of events from Windows devices
- Configuring centralized receipt of events from Windows devices using the Windows Event Collector service
- Granting permissions to view Windows events
- Granting permissions to log on as a service
- Configuring the KUMA Collector for receiving events from Windows devices
- Installing the KUMA Collector for receiving events from Windows devices
- Configuring forwarding of events from Windows devices to KUMA using KUMA Agent (WEC)
- Configuring receipt of events from Windows devices using KUMA Agent (WMI)
- Configuring receipt of PostgreSQL events
- Configuring receipt of IVK Kolchuga-K events
- Configuring receipt of CryptoPro NGate events
- Configuring receipt of Ideco UTM events
- Configuring receipt of KWTS events
- Configuring receipt of KLMS events
- Configuring receipt of KSMG events
- Configuring receipt of PT NAD events
- Configuring receipt of events using the MariaDB Audit Plugin
- Configuring receipt of Apache Cassandra events
- Configuring receipt of FreeIPA events
- Configuring receipt of VipNet TIAS events
- Configuring receipt of Nextcloud events
- Configuring receipt of Snort events
- Configuring receipt of Suricata events
- Configuring receipt of FreeRADIUS events
- Configuring receipt of VMware vCenter events
- Configuring receipt of zVirt events
- Configuring receipt of Zeek IDS events
- Configuring DNS server event reception using the ETW connector
- Configuring Windows event reception using Kaspersky Endpoint Security for Windows
- Configuring receipt of Codemaster Mirada events
- Configuring receipt of Postfix events
- Configuring receipt of CommuniGate Pro events
- Configuring receipt of Yandex Cloud events
- Configuring receipt of Microsoft 365 events
- Configuring receipt of the Kontinent encryption system events
- Monitoring event sources
- Managing assets
- Adding an asset category
- Configuring the table of assets
- Searching assets
- Exporting asset data
- Viewing asset details
- Adding assets
- Adding asset information in the KUMA Console
- Importing asset information from Kaspersky Security Center
- Importing asset information from MaxPatrol
- Importing asset information from KICS for Networks
- Examples of asset field comparison during import
- Settings of the kuma-ptvm-config.yaml configuration file
- Assigning a category to an asset
- Editing the parameters of assets
- Archiving assets
- Deleting assets
- Updating third-party applications and fixing vulnerabilities on Kaspersky Security Center assets
- Moving assets to a selected administration group
- Asset audit
- Custom asset fields
- Critical information infrastructure assets
- Integration with other solutions
- Integration with Kaspersky Security Center
- Kaspersky Endpoint Detection and Response integration
- Integration with Kaspersky CyberTrace
- Integration with Kaspersky Threat Intelligence Portal
- Connecting over LDAP
- Enabling and disabling LDAP integration
- Adding a tenant to the LDAP server integration list
- Creating an LDAP server connection
- Creating a copy of an LDAP server connection
- Changing an LDAP server connection
- Changing the data update frequency
- Changing the data storage period
- Starting account data update tasks
- Deleting an LDAP server connection
- Kaspersky Industrial CyberSecurity for Networks integration
- Integration with Neurodat SIEM IM
- Kaspersky Automated Security Awareness Platform
- Sending notifications to Telegram
- UserGate integration
- Integration with Kaspersky Web Traffic Security
- Integration with Kaspersky Secure Mail Gateway
- Importing asset information from RedCheck
- Configuring receipt of Sendmail events
- Managing KUMA
- Working with geographic data
- User guide
- KUMA resources
- Operations with resources
- Destinations
- Normalizers
- Aggregation rules
- Enrichment rules
- Correlation rules
- Filters
- Active lists
- Viewing the table of active lists
- Adding active list
- Viewing the settings of an active list
- Changing the settings of an active list
- Duplicating the settings of an active list
- Deleting an active list
- Viewing records in the active list
- Searching for records in the active list
- Adding a record to an active list
- Duplicating records in the active list
- Changing a record in the active list
- Deleting records from the active list
- Import data to an active list
- Exporting data from the active list
- Predefined active lists
- Dictionaries
- Response rules
- Connectors
- Viewing connector settings
- Adding a connector
- Connector settings
- Secrets
- Context tables
- Viewing the list of context tables
- Adding a context table
- Viewing context table settings
- Editing context table settings
- Duplicating context table settings
- Deleting a context table
- Viewing context table records
- Searching context table records
- Adding a context table record
- Editing a context table record
- Deleting a context table record
- Importing data into a context table
- Analytics
- KUMA resources
- Working with Open Single Management Platform
- Basic concepts
- Administration Server
- Hierarchy of Administration Servers
- Virtual Administration Server
- Web Server
- Network Agent
- Administration groups
- Managed device
- Unassigned device
- Administrator's workstation
- Management web plug-in
- Policies
- Policy profiles
- Tasks
- Task scope
- How local application settings relate to policies
- Distribution point
- Connection gateway
- Configuring Administration Server
- Configuring the Administration Server connection address
- Configuring the connection of OSMP Console to Administration Server
- Configuring internet access settings
- Certificates for work with Open Single Management Platform
- About Open Single Management Platform certificates
- Requirements for custom certificates used in Open Single Management Platform
- Reissuing the certificate for OSMP Console
- Replacing certificate for OSMP Console
- Converting a PFX certificate to the PEM format
- Scenario: Specifying the custom Administration Server certificate
- Replacing the Administration Server certificate by using the klsetsrvcert utility
- Connecting Network Agents to Administration Server by using the klmover utility
- Hierarchy of Administration Servers
- Creating a hierarchy of Administration Servers: adding a secondary Administration Server
- Viewing the list of secondary Administration Servers
- Managing virtual Administration Servers
- Configuring Administration Server connection events logging
- Setting the maximum number of events in the event repository
- Changing DBMS credentials
- Backup copying and restoration of the Administration Server data
- Deleting a hierarchy of Administration Servers
- Access to public DNS servers
- Configuring the interface
- Encrypt communication with TLS
- Backup copying and restoration of KUMA Core under Kaspersky Next XDR Expert
- Discovering networked devices
- Managing client devices
- Settings of a managed device
- Creating administration groups
- Device moving rules
- Adding devices to an administration group manually
- Moving devices or clusters to an administration group manually
- About clusters and server arrays
- Properties of a cluster or server array
- Adjustment of distribution points and connection gateways
- Standard configuration of distribution points: Single office
- Standard configuration of distribution points: Multiple small remote offices
- Calculating the number and configuration of distribution points
- Assigning distribution points automatically
- Assigning distribution points manually
- Modifying the list of distribution points for an administration group
- Enabling a push server
- About device statuses
- Configuring the switching of device statuses
- Device selections
- Device tags
- Device tags
- Creating a device tag
- Renaming a device tag
- Deleting a device tag
- Viewing devices to which a tag is assigned
- Viewing tags assigned to a device
- Tagging a device manually
- Removing an assigned tag from a device
- Viewing rules for tagging devices automatically
- Editing a rule for tagging devices automatically
- Creating a rule for tagging devices automatically
- Running rules for auto-tagging devices
- Deleting a rule for tagging devices automatically
- Data encryption and protection
- Changing the Administration Server for client devices
- Viewing and configuring the actions when devices show inactivity
- Remote access to managed devices
- Remote access from a Linux-based device with OSMP Console to a Linux-based managed device
- Remote access from a Linux-based device with OSMP Console to a Windows-based managed device
- Remote access from a Windows-based device with OSMP Console to a Linux-based managed device
- Remote access from a Windows-based device with OSMP Console to a Windows-based managed device
- Deploying Kaspersky applications
- Scenario: Kaspersky applications deployment
- Protection deployment wizard
- Step 1. Starting Protection deployment wizard
- Step 2. Selecting the installation package
- Step 3. Selecting a method for distribution of key file or activation code
- Step 4. Selecting Network Agent version
- Step 5. Selecting devices
- Step 6. Specifying the remote installation task settings
- Step 7. Restart management
- Step 8. Removing incompatible applications before installation
- Step 9. Moving devices to Managed devices
- Step 10. Selecting accounts to access devices
- Step 11. Starting installation
- Adding management plug-ins for Kaspersky applications
- Removing management web plug-ins
- Viewing the list of components integrated in Open Single Management Platform
- Viewing names, parameters, and custom actions of Kaspersky Next XDR Expert components
- Downloading and creating installation packages for Kaspersky applications
- Creating installation packages from a file
- Creating stand-alone installation packages
- Changing the limit on the size of custom installation package data
- Installing Network Agent for Linux in silent mode (with an answer file)
- Preparing a device running Astra Linux in the closed software environment mode for installation of Network Agent
- Viewing the list of stand-alone installation packages
- Distributing installation packages to secondary Administration Servers
- Preparing a Linux device and installing Network Agent on a Linux device remotely
- Installing applications using a remote installation task
- Specifying settings for remote installation on Unix devices
- Starting and stopping Kaspersky applications
- Replacing third-party security applications
- Removing applications or software updates remotely
- Preparing a device running SUSE Linux Enterprise Server 15 for installation of Network Agent
- Preparing a Windows device for remote installation
- Configuring Kaspersky applications
- Scenario: Configuring network protection
- About device-centric and user-centric security management approaches
- Policy setup and propagation: Device-centric approach
- Policy setup and propagation: User-centric approach
- Policies and policy profiles
- About policies and policy profiles
- About lock and locked settings
- Inheritance of policies and policy profiles
- Managing policies
- Viewing the list of policies
- Creating a policy
- General policy settings
- Modifying a policy
- Enabling and disabling a policy inheritance option
- Copying a policy
- Moving a policy
- Exporting a policy
- Importing a policy
- Forced synchronization
- Viewing the policy distribution status chart
- Activating a policy automatically at the Virus outbreak event
- Deleting a policy
- Managing policy profiles
- Network Agent policy settings
- Usage of Network Agent for Windows, Linux, and macOS: Comparison
- Comparison of Network Agent settings by operating systems
- Manual setup of the Kaspersky Endpoint Security policy
- Configuring Kaspersky Security Network
- Checking the list of the networks protected by Firewall
- Disabling the scan of network drives
- Excluding software details from the Administration Server memory
- Configuring access to the Kaspersky Endpoint Security for Windows interface on workstations
- Configuring the registration of policy events in the Administration Server database
- Manual setup of the group update task for Kaspersky Endpoint Security
- Kaspersky Security Network (KSN)
- Managing tasks
- About tasks
- About task scope
- Creating a task
- Starting a task manually
- Starting a task for selected devices
- Viewing the task list
- General task settings
- Exporting a task
- Importing a task
- Starting the Change tasks password wizard
- Viewing task run results stored on the Administration Server
- Manual setup of the group task for scanning a device with Kaspersky Endpoint Security
- General task settings
- Application tags
- Granting offline access to the external device blocked by Device Control
- Registering Kaspersky Industrial CyberSecurity for Networks application in OSMP Console
- Managing users and user roles
- About user accounts
- About user roles
- Configuring access rights to application features. Role-based access control
- Adding an account of an internal user
- Creating a security group
- Editing an account of an internal user
- Editing a security group
- Assigning a role to a user or a security group
- Adding user accounts to an internal security group
- Assigning a user as a device owner
- Two-step verification
- Scenario: Configuring two-step verification for all users
- About two-step verification for an account
- Enabling two-step verification for your own account
- Enabling required two-step verification for all users
- Disabling two-step verification for a user account
- Disabling required two-step verification for all users
- Excluding accounts from two-step verification
- Configuring two-step verification for your own account
- Prohibit new users from setting up two-step verification for themselves
- Generating a new secret key
- Editing the name of a security code issuer
- Changing the number of allowed password entry attempts
- Deleting a user or a security group
- Changing the password for a user account
- Creating a user role
- Editing a user role
- Editing the scope of a user role
- Deleting a user role
- Associating policy profiles with roles
- Updating Kaspersky databases and applications
- Scenario: Regular updating Kaspersky databases and applications
- About updating Kaspersky databases, software modules, and applications
- Creating the Download updates to the Administration Server repository task
- Viewing downloaded updates
- Verifying downloaded updates
- Creating the task for downloading updates to the repositories of distribution points
- Adding sources of updates for the Download updates to the Administration Server repository task
- Approving and declining software updates
- Automatic installation of updates for Kaspersky Endpoint Security for Windows
- About using diff files for updating Kaspersky databases and software modules
- Enabling the Downloading diff files feature
- Downloading updates by distribution points
- Updating Kaspersky databases and software modules on offline devices
- Remote diagnostics of client devices
- Opening the remote diagnostics window
- Enabling and disabling tracing for applications
- Downloading trace files of an application
- Deleting trace files
- Downloading application settings
- Downloading system information from a client device
- Downloading event logs
- Starting, stopping, restarting the application
- Running the remote diagnostics of Kaspersky Security Center Network Agent and downloading the results
- Running an application on a client device
- Generating a dump file for an application
- Running remote diagnostics on a Linux-based client device
- Managing third-party applications and executable files on client devices
- Using Application Control to manage executable files
- Application Control modes and categories
- Obtaining and viewing a list of applications installed on client devices
- Obtaining and viewing a list of executable files stored on client devices
- Creating an application category with content added manually
- Creating an application category that includes executable files from selected devices
- Creating an application category that includes executable files from selected folder
- Viewing the list of application categories
- Configuring Application Control in the Kaspersky Endpoint Security for Windows policy
- Adding event-related executable files to the application category
- Creating the Install required updates and fix vulnerabilities task
- Find vulnerabilities and required updates task settings
- About the license
- API Reference Guide
- Basic concepts
- Monitoring, reporting, and audit
- Scenario: Monitoring and reporting
- About types of monitoring and reporting
- Triggering of rules in Smart Training mode
- Dashboard and widgets
- Reports
- Events and event selections
- About events in Open Single Management Platform
- Events of Open Single Management Platform components
- Using event selections
- Creating an event selection
- Editing an event selection
- Viewing a list of an event selection
- Exporting an event selection
- Importing an event selection
- Viewing details of an event
- Exporting events to a file
- Viewing an object history from an event
- Deleting events
- Deleting event selections
- Setting the storage term for an event
- Blocking frequent events
- Event processing and storage on the Administration Server
- Notifications and device statuses
- Kaspersky announcements
- Cloud Discovery
- Exporting events to SIEM systems
- Configuring event export to SIEM systems
- Before you begin
- About event export
- About configuring event export in a SIEM system
- Marking of events for export to SIEM systems in Syslog format
- About exporting events using Syslog format
- Configuring Open Single Management Platform for export of events to a SIEM system
- Exporting events directly from the database
- Viewing export results
- Managing object revisions
- Deletion of objects
- Downloading and deleting files from Quarantine and Backup
- Operation diagnostics of the Kaspersky Next XDR Expert components
- Multitenancy
- Contact Technical Support
- Known issues
- Appendices
- Commands for components manual starting and installing
- Integrity check of KUMA files
- Normalized event data model
- Configuring the data model of a normalized event from KATA EDR
- Asset data model
- User account data model
- KUMA audit events
- Event fields with general information
- User successfully signed in or failed to sign in
- User successfully logged out
- Service was successfully created
- Service was successfully deleted
- Service was successfully started
- Service was successfully paired
- Service was successfully reloaded
- Service was successfully restarted
- Storage partition was deleted automatically due to expiration
- Storage partition was deleted by user
- Active list was successfully cleared or operation failed
- Active list item was successfully changed, or operation was unsuccessful
- Active list item was successfully deleted or operation was unsuccessful
- Active list was successfully imported or operation failed
- Active list was exported successfully
- Resource was successfully added
- Resource was successfully deleted
- Resource was successfully updated
- Asset was successfully created
- Asset was successfully deleted
- Asset category was successfully added
- Asset category was deleted successfully
- Settings were updated successfully
- The dictionary was successfully updated on the service or operation was unsuccessful
- Response in Active Directory
- Response via KICS for Networks
- Kaspersky Automated Security Awareness Platform response
- KEDR response
- Correlation rules
- Time format
- Mapping fields of predefined normalizers
- Glossary
- Administrator host
- Agent
- Alert
- Asset
- Bootstrap
- Collector
- Configuration file
- Context
- Correlation rule
- Correlator
- Custom actions
- Distribution package
- Event
- Incident
- Investigation graph
- Kaspersky Deployment Toolkit
- Kubernetes cluster
- KUMA inventory file
- KUMA services
- Lightweight Nagent (LWNGT)
- Multitenancy
- Network Agent
- Network Location Awareness (NLA)
- Node
- Normalized event
- Observables
- Playbook
- Playbook algorithm
- Registry
- Response actions
- Segmentation rules
- Storage
- Target hosts
- Tenant
- Threat development chain
- Transport archive
- Information about third-party code
- Trademark notices
Granular access to events
In KUMA, users with different rights can have granular access to events. Access to events is controlled at the level of storage spaces.
You can assign spaces to users in the Spaces permissions section. After upgrading to the latest version, the 'All spaces' space set is assigned to all existing users, that is, access to all spaces is unrestricted. An event contains a tenant ID and a space ID, therefore the user needs rights to the corresponding tenant and space to have access to the event.
Keep in mind the following special considerations involved in displaying storages:
- If a storage is not listed in the Active services section, the storage and its spaces are not displayed in the list of spaces of the set.
- If the storage service was stopped using the
systemctl stop kuma-<storage ID>
command, the storage and its spaces are not displayed in the list of spaces of the set. - If the storage was started and then deleted using the
uninstall
command, the storage and its spaces remain in the list of spaces of the set.
In the list of events, you can add the SpaceID field to the table, which will display the name of the space. The space of audit events is displayed as KUMA Audit. KUMA Default is the space inside each storage, where all events go if the storage does not have configured spaces or if the event does not match the conditions of the existing spaces.
When you export the list of events to a TSV file, the space ID and name are displayed for spaces.
To differentiate access:
- Configure the space sets.
You can create, edit, or delete space sets. These actions result in audit events.
- Configure the access rights of the space set: you can grant or revoke access rights of selected users.
To create a space set:
- In the KUMA Console, go to the Settings → Spaces permissions section.
- In the Spaces permissions window, click the Add button.
- In the Create space set window, configure the following:
- In the Name field, specify the space set name. You can use up to 128 Unicode characters.
- In the Spaces drop-down list, select the spaces that you want to include in the set by selecting the check box next to the space name. To remove a space from the set, clear the check box.
- If you want the default space set to be available to all users that do not have any of the sets assigned, select the Make default check box.
This makes the created set the default set. In the list of space sets, it is marked as the default set: in the Default column, it has Yes.
There can be only one default set. If you select Make default check box in the settings of a different set and save the settings, the default set is reassigned.
- Click Create.
The space set is created and displayed in the list of spaces. After the space set is created, an audit event is generated in KUMA.
Then you need to grant users access rights to the created space set.
To edit a space set:
- In the KUMA Console, go to the Settings → Spaces permissions section.
- In the Spaces permissions window, click a set of spaces.
- In the Edit space set window, configure the following:
- In the Name field, specify the space set name. You can use up to 128 Unicode characters.
- In the Spaces drop-down list, select the spaces that you want to include in the set by selecting the check box next to the space name. To remove a space from the set, clear the check box.
- If you want the default space set to be available to all users that do not have any of the sets assigned, select the Make default check box.
This makes the set the default set when you save the changes. In the list of space sets, it is marked as the default set: in the Default column, it has Yes.
There can be only one default set. If you select Make default check box in the settings of a different set and save the settings, the default set is reassigned.
- Click Save.
The space set is saved and displayed in the list of spaces.
The edited set of spaces is accessible to all users who had access to the original space set. You can control access to the edited space set and grant or revoke access permissions using the Access control button.
To delete a space set:
- In the KUMA Console, go to the Settings → Spaces permissions section.
- In the Spaces permissions window, select the check box next to the relevant space set.
If you want to delete all space sets, select the Select all check box in the upper left part of the list and click Delete. The default All spaces set cannot be deleted.
- Click Delete.
The space set is deleted and removed from the list of spaces. After the space set is deleted, an audit event is generated in KUMA.
If a user had access only to the deleted space set and did not have access to any other sets, such a user automatically gets access rights to the default set.
To grant access to a space set
- In the KUMA Console, go to the Settings → Spaces permissions section.
- Select a set of spaces in the list by selecting the check box next to it, then click the Access control button on the toolbar.
- This opens the Users window; in that window, click Add users.
- In the list in the Add users window, select users to which you want to grant access to the space set and click Add.
If you want to grant access to the selected space set to all users, select the check box in the upper left corner and select one of the following options: Select all in page or Select all, then click Add.
This opens a confirmation window.
- If you want to grant access to the listed users, click Grant in the confirmation window.
The users now have access to the space set.
To revoke access to a space set:
- In the KUMA Console, go to the Settings → Spaces permissions section.
- Select a set of spaces in the list by selecting the check box next to it, then click the Access control button on the toolbar.
- This opens the Users window; in that window, select users by selecting their check boxes, then click Delete.
If you want to revoke access to the selected space set from all users, select the check box in the upper left corner and select one of the following options: Select all in page or Select all, then click Delete.
This opens a confirmation window.
- If you want to revoke access from the listed users, click Revoke in the confirmation window.
The users no longer have access to the space set.
If a user does not have access to any other space set, such a user automatically gets access to the default set.
Use cases
Migrating to the latest KUMA version with differentiated access to events
Goal: Update the product.
Action: The administrator updates KUMA to version 3.4.
Result: The accessibility of events does not change for users; all users have access to events in those tenants in which users are allowed to view the list of events. When adding new users, tenants, or spaces, all users see the events of tenants depending on whether they are allowed to view the list of events, with no further restrictions.
Restricting access to spaces for all users
Goal: Some spaces in the installation must be inaccessible to some users. Current and new users must not have access to such spaces.
Action: The administrator creates a new set of spaces that includes the spaces to which all users must have access. Each space is specified as a tuple: clusterID, tenantID, spaceID. In this way, you can assemble a set of spaces from a finite number of spaces. After creating the set, the administrator makes this set the default set.
Result: For all users that do not have this space set explicitly specified, including new users, access to events is additionally restricted in accordance with the default space set. That is, such users have access to events in tenants in which the user has the right to view the list of events, and events in spaces that are included in the default set.
Allowing some users to view all events
Goal: KUMA has a default set in which only a finite number of spaces is explicitly specified. Also some users in KUMA must have unrestricted access to all events. You want to allow these users to view events from spaces that are not specified in the default set.
Action: The administrator goes to the Spaces permissions section and selects the All spaces set, which gives access to all spaces without restrictions, and grants access to this set to the selected users.
Result: Users that have been explicitly granted access to the All spaces set now have unrestricted access to events in spaces. Their access to events depends only on the right to view the list of events in accordance with their assigned role. When you add new spaces or tenants, these users will have access to the events located in these new spaces and tenants, provided they have the right to view the list of events for the corresponding tenant. Users that have not been explicitly granted access to the All spaces set will have restricted access to events in accordance with the default set of spaces.
Permitting some users to view events from a finite set of spaces
Goal: KUMA has a default set in which only a finite number of spaces is explicitly specified. Some users need to see a different space set, but not all available spaces.
Action: The administrator creates a space set that includes the relevant spaces and grants access to this set to the selected users.
Result: User access to events is restricted in accordance with the available space set. Users that have not been explicitly granted access to the set will have restricted access to events in accordance with the default set of spaces.
Supplementing an explicitly specified space set for a user
Goal: Users u1, u2, u3, u4 have been explicitly granted access to space set 'set1', which includes spaces to which Windows and Linux events go. Users u1 and u2, in addition to Windows and Linux events, need to view Cisco and VMware events that go to the respective spaces.
Action: The administrator creates a set of spaces, 'set2', which includes the spaces of Cisco and VMware events. The administrator assigns set2 to u1 and u2 in addition to set1.
Result: Users u1 and u2 now have access to events from the spaces of all of the sets available to them, that is, events from the set1 and set2: Windows, Linux, Cisco, VMware. Access of users u3 and u4 to events remains unchanged.
Goal: Some users have access to a space set (access is granted explicitly or the set is the default set). For all of these users, you need to add access to a certain space that is not in the set, or revoke access to a space that is in the set.
Action: The administrator edits the existing set of spaces by adding or removing the relevant spaces.
Result: All users that have access to the set can now view events in accordance with the updated space set.
Goal: The space set is no longer relevant, and it needs to be deleted from KUMA.
Action: The administrator deletes an existing space set. The All spaces set cannot be deleted. The default space set cannot be deleted.
Result: The deleted space set is gone from KUMA. All users that have been explicitly granted access to this set of spaces now have access to events in accordance with the space sets that remain available to them. If a user does not have any space sets left to which access has been explicitly granted, such a user's access to events is controlled by the default set.