Users and Tenants

The admin user can do anything with a Hotrod system. It gets its power from the admin role, so if you wish you can create multiple admin users.

hotrod users add mike 'Michael Snipes' --roles 'user,admin'

That is, a Hotrod 'super-user' is a user with the 'user' and the 'admin' roles.

This is recommended practice, since users appear in the audit logs:

$ hotrod daemon logs
 timestamp           | level | message
---------------------+-------+------------------------------------------------------------
 2020-10-26T13:42:55 | INFO  | saving license from HOTROD_LICENSE_KEY
 2020-10-26T13:42:56 | INFO  | user=admin successful login from 127.0.0.1:56974
 2020-10-26T13:42:56 | INFO  | user=admin adding pipe=uptime to target=Cape Town
 2020-10-26T13:42:57 | INFO  | user=admin creating user=bob
 2020-10-26T13:42:57 | INFO  | user=bob successful login from 127.0.0.1:56988
 2020-10-26T13:42:57 | INFO  | user=bob adding pipe=ping to target=Durban

Restricting Access with Tenants

A target has an identifier, a human-readable name, associated tags, and a tenant.

The usual meaning of 'tenant' is the particular customer associated with the target, but it is a convenient way to divide the network of target nodes into areas of responsibility.

Regular admin users can effectively do anything to any of the target nodes, which makes them too powerful for most system management roles. However, if a user has a 'admin' role and a associated tenant, then that user can only operate on targets sharing that tenant.

hotrod users add Bob 'Bobs Burgers' --roles 'user,admin' --tenant-ids 'Western Cape'

The user Bob only has power over a subset of the targets. The other restrictions occur because a tenant user like Bob may not have any power over other targets: they cannot modify the global or tag contexts, because these are shared for all targets.

Taming the Agent

Nodes of a Hotrod network are not just single-purpose data collectors like Bboxes, but can be servers requiring monitoring. These servers can be rather more important than the Hotrod server itself! Making the sysadmin a Hotrod tenant admin gives them full control over Hotrod operations on the systems they are responsible for, without giving them access to other systems which are not their responsibility.

By default, hotrod-agent will poll the hotrodd server (the --poll-interval value in seconds) and if the server state has changed, the agent will download any updated pipes. This central control is appropriate for a fleet of collectors, but sometimes the agent is a guest on a system.

If --poll-interval is set to zero, then the agent does not poll at a fixed interval. Instead, it waits for a notification. Logs and volume reports will still be transferred, but no automatic updates take place. Instead, the administrator will review the changes, and then explicitly runs:

hotrod-agent --update

It is further possible to enforce acceptable pipe policy on the agent level with the --exclude-pipe-features option. It is given a list of features from this list:

  • exec the pipe may not run any commands (input-exec,action-exec or output-exec)
  • exe the files associated with the pipe may not be executable
  • script no scripting whatsoever
  • init-lua may have script actions, but no custom init.lua