Users and Tenants

The admin user can do anything with a HOTROD system. The admin role has full rights, so if you wish you can create multiple admin users.

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

That is, a "superuser" is a user with the user and admin roles.

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

$ hotrod server 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 agent=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 agent=Durban

Restricting Access with Tenants

An Agent has an ID, a human-readable name, associated Tags, and a Tenant.

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

Regular admin users can effectively do anything to any of the Agent nodes, which makes them too powerful for most system management roles. However, if a user has an admin role and an associated --tenant-ids, then that user can only operate on Agents 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 Agents. The other restrictions occur because a Tenant user like Bob may not have any power over other Agents: they cannot modify the global or Tag Context, because these are shared for all Agents.

Taming the Agent

Nodes on a network can be seen as servers requiring monitoring. These servers may be more important than the Server itself. Making the admininistrator a Tenant admin, gives them full control over operations and access only to the systems they are responsible for.

By default, the Agent will poll the Server (--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 run:

$> hotrod-agent --update

It is further possible to enforce acceptable Pipe policy on the Agent level with the --exclude-pipe-features option. It's 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