Implement token based access control

[kshpytsya]

The access control aspect does not seem to be mentioned anywhere. My two cents on this would be the following (probably somewhat inspired by consul/vault):

Access control mechanism should be explicitly enabled in oklog's command line. When disabled, oklog's functionality should be completely unchanged. Read and write access control should be probably enabled separately. TBD: it may make sense to be able to enable access control both at global (disabled by default) and per-topic (overriding global setting) level.

Let us define a token to be an arbitrary string that does not contain spaces and new-lines. Practically, this would probably be some kind of uuid but oklog should treat them as opaque.

Let us define access control list (ACL) to be a list of token pairs: access token, id token (akin to vault's "token accessor"). ACLs are stored as plain text files with one entry per line, and access and id token being separated by space. "id token" is to be used as a non-secret reference to "access token" in various access logs (are there any?).

A new "update config" REST API is to be added to "oklog". Parameters would be "access token", "topic" (or empty for global configs), "config name" (a short string), and "config value" (a long string). Access token is to be used to restrict calls to this API to bearers of tokens from admin ACL (either global or topic-specific when setting topic-specific config, and global when setting global configs). As a part of the call, the config should be parsed according to rules for this particular config (e.g. above-described format for ACL storage, in case of ACL configs), parsing errors should be reported to caller and config should remain unchanged. Dynamic configs should be stored as plain text files in a a directory managed by oklog. Writing should be performed in "write to temp, then rename" fashion. This API could be made a bit more flexible by accepting a list of "topic", "config name", "config value" tuples, and making an attempt for atomic update (at least, parse and write to temp all the configs, and then do the rename pass; a stricter atomicity could be implemented by complete copying of entire set of config files into new directory, and renaming the directory at the end).
The first use for this dynamic config mechanism would be dynamic update of ACLs.
Upon server start, all dynamic configs should be read from files, any parsing errors should be fatal.
Each oklog instance would have it's own dynamic config store (directory). Initial provisioning and updating configs (via above described API) across all instances is outside of oklog's scope.

There are three ACLs per topic and three global ACLs: readers, writers and admins.

There should also be a global "master" admin ACL, supplied as a file name via command line option, that would be unmodifiable via API. This is to prevent lock-out situations that could occur due to accidental or malicious deletion of admin tokens.

If read access control is enabled, query operations should require supplying of a token from either topic-specific or global ACL. If token is omitted, an "anonymous" token should be used.

If write access control is enabled, each ingested log entry should start with an access token followed by a single space. Tokens from global write ACL allow writing to all topics. Tokens from per-topic write ACLs allow writing to corresponding topics. Writes without a valid token should be silently ignored, possibly adding an error entry to access log. Upon ingestion, "access token" is substituted with "token id". This both allows traceability (i.e., knowing, which token was used to produce any particular log entry) and keeps access tokens secret (without this substitution, all readers would be able to see write tokens).