One of the features introduced in the 4.15 NetEye release is the Command Orchestrator. The aim of this newly introduced feature module is to allow limited-access NetEye users to execute predefined commands on hosts, without needing full access to the targeted device. Within the Command Orchestrator, the NetEye administrator defines which commands can be executed, by which NetEye users, and on which hosts.
A scenario where Command Orchestrator can be of great help to a company is when an IT operations team, in order to reduce the MTTR (mean-time-to-repair), needs to delegate a set of recurrent operations on their systems to a group like a support team, but without giving them privileged access to the machines. With the Command Orchestrator, the NetEye admin can configure the commands needed to perform these recurrent operations, and the support team can then execute these commands through the Command Orchestrator as well.
Currently the Command Orchestrator allows for 3 types of commands: Local, Remote and Weblink.
Local – Commands executed on NetEye itself
Remote – Commands executed on remote hosts
Weblink – Commands which, upon execution, simply open a predefined URL in the user’s browser
For the execution of the Local and Remote command types, the Command Orchestrator relies on the Execute Command Icinga2 API. This API was recently developed by the NetEye R&D team in collaboration with the Icinga2 developers.
Allowing limited NetEye users to execute commands on remote hosts is a very powerful feature, which could however have potentially raised security concerns if it was not well designed.
For this reason, the following user restrictions were introduced by design in the Command Orchestrator in order to avoid allowing them to perform unwanted actions:
Users can only execute a command which was previously defined by the Command Orchestrator administrator
Users can only execute commands if they have access to the Command Orchestratormodule and have the execute-command permission enabled
Users can only execute commands which the NetEye admin has given them access to
The parameters along with which a command is executed can only take the predefined values allowed by the Command Orchestrator admin
Users can only execute commands on hosts which they have Monitoring access to
A command can only be executed on hosts respecting the Monitoring Object Filter defined by the Command Orchestrator admin, for that specific command
In order to allow for easier management of commands in the Command Orchestrator, we also decided to give the NetEye admin the possibility to create groups of commands, with groups recursively containing other groups, so to form a tree structure where the leaves are the commands. Again, with the goal of keeping configurations simple, users’ permissions are configured directly on command groups, so that redundant and error-prone configurations can be avoided.
Today we continue our journey into monitoring automation in NetEye. In my previous post we discussed the possibility of automating Business Processes. As you may remember, for those of us working on NetEye Cloud monitoring dozens of clients, it's important Read More
In organizations using Confluence Cloud as a knowledge‑base, documentation hub or collaboration platform, you often see pages or spaces created with restrictions (visible only to certain users/groups). In these situations an administrator may need to access content they don’t have Read More
A very important, fast-evolving area during the latest NetEye releases has been multi-tenancy. In a system with many tenants, the most complex aspect is probably the proper and orderly management of user permissions. To help administrators in this task, we Read More
NetEye 4 Log Manager, as already presented in this blog post, allows you to easily manage the collection, navigation, visualization and analysis of large numbers of logs. For many reasons, I as a user may want to limit log access Read More