Gantry Operator Hierarchies

Operator Hierarchies

Gantry supports the notion of secure multi-tenancy by default. When the Gantry server starts up, it requires that an operator token be passed to it on the command line (which, of course, can come from an environment variable, a container-mounted volume, etc). Remember that this JWT is verifiable offline, and contains no secrets.

Each Gantry server catalog (managed by the catalog actor) can store and validate multiple operators. These operators, in turn, verify multiple accounts, as illustrated in the following diagram:

There are a couple of very good reasons for the gantry-server application requiring the runtime injection of a root operator token. The root operator token contains the list of that operator’s public signing keys. This amounts to a “whitelist” of the operators that can exist in the catalog (anything issued by any of the signing keys). You can think of this as requiring a second factor that, when when activated, validates an entire catalog of tokens. New operators cannot be inserted into the database unless they were signed by one of the keys referenced in this token.

Without this additional step, if an intruder were able to gain write access to the database, they could fabricate their own root operator, mint new operators issued by that one, and continue this until they crafted malicious (but valid) actor tokens. With this approach to the operator hierarchy, an intruder needs to have both write access to the database and at least one private signing key from the root operator to mint fake tokens.