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 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 identifier, 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, 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 contexts, because these are shared for all agents.

Taming the Agent

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

By default, the Hotrod Agent will poll the Hotrod 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'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