Grafana API Token Access

[patrickbrophy]

Currently accessing Prometheus from Grafana is tricky. To mitigate this difficulty, we want to introduce an API token that when provided, allows access to Prometheus. This token should be persisted in a database. The tokens should be salted and hashed before being stored into the database.

Token management should be provided via a CRUD API. This new API would then be hooked up to the Pelican Web UI so that admins can manage these new tokens. This API should only be accessible to administrators.

[bbockelm]

A few thoughts on the implementation:

• I really dislike how we've come to have per-server SQLite database locations (Origin.DbLocation, Registry.DbLocation, Director.DbLocation). There should be a single database, for Pelican. Don't solve the problem in this issue -- however, let's also not make it any worse. Instead, let's create a new parameter, Server.DbLocation, that the others can eventually migrate to.
• Do not store raw secrets: Use golang.org/x/crypto/bcrypt to hash the token on disk.
• Unfortunately, verifying the hashed API key is computationally expensive (by design). On success, keep a TTL cache of verified API keys. This cache will need to be updated whenever changes to the API tokens are needed (e.g., invalidate entries when a token deletion is done).
  • Rate limit the verification of API keys. There's an example of doing this already for the login API, I think.
• Given we don't store secrets, the token needs an ID (a handle we can refer to when invalidating it, for example). One approach is to have the ID be the first 5 characters of the SHA-256 checksum of the token. Since you're generating this, there's a chance of collision: on collision with an existing API key in the DB, simply retry the generation.
  • The contents of the token could be serialized in the form ID.SECRET (as in, ab258.12b7fa82190d). That way, even though we currently generate the ID, it's not forced to be the value of the checksum and we could change the algorithm in the futuer.
• Attributes of an API key that likely need to be persisted:
  • (Unique) ID. Do not use a monotonically-increasing integer. Indexed.
  • Human-readable name.
  • Expiration time.
  • List of scopes. May need to be normalized out to a separate table (probably indexed by token ID).
  • Creation time & identity of creator.
  • Last change time & identity.
  • Salted token value.

So, if the token is ab258.12b7fa82190d, then we would:

1. Look at the TTL cache of verified tokens for ab258.12b7fa82190d and use that entry.
2. Otherwise, query the DB for the row with ID ab258 and see if 12b7fa82190d matches the salted hash stored in the database.
3. If it does (and it's not expired), then we would drop a copy of the record in the TTL cache for verified tokens.

Notice the above is generic - nothing to do with Prometheus API! From the entry, we will have a list of approved scopes and we can hopefully retain some of the existing scope-based authorization scope (in this case, the scope comes from the internal database, not the token).