Option to support a shared secret token auth scheme

[parente]

Right now, the tmpnb spawn, stats, etc. end points are wide open for anyone to request access to a new container. This is great for open deployments, not so great for cases where only certain actors should be allowed to request containers. An optional API key scheme would do the trick here. I suggest keeping with what we did in jupyter-server/kernel_gateway#3, generate a single shared token on startup, log it, require it in the form:

Authorization: token <the api key>

I'll probably wind up tackling this in a PR. Opening it so I don't forget. Did discuss it briefly with @rgbkrk

[rgbkrk]

That seems good even on the wide open version. Whatever frontend is around can provide these as temp tokens.

[parente]

Whatever frontend is around can provide these as temp tokens.

Missed your drift here. /me slurps more coffee

[rgbkrk]

drift is right, sorry. I was thinking that tmpnb can require tokens no matter what and the version at try.jupyter.org just gives them out freely.

[parente]

Hmm. Does that mean there's a new endpoint for requesting a token too? My brain is stuck on the bootstrap process. The silly simple KISS implementation in kernel gateway generates a token on gateway startup and requires sharing it out-of-band (e.g., I tell you the key and you put it in your app.)

[rgbkrk]

That makes sense. Each container/notebook server gets their own token on boot I presume?

[rgbkrk]

Or is this a token for just requesting a kernel to begin with?

[rgbkrk]

Ok, reading over, that's the case here.

[parente]

Realtime chat in github issue! Yes. The latter. But the former is a follow on for sure.

To summarize:

1. Cluster API key lets you request a container = this issue
2. API key for thing(s) running in the container you requested returned along with the URL of the container = deeper integration for later, but already supported by, for example, kernel gateway via env vars

The stopgap for 2. is make the two API keys the same. If you can request a container, you can talk to any container. Single tenant story.

[parente]

Occurs to me as I'm coming back to this that we may not even need the second API key. The URL itself already has a key of sorts in the form of the unique user ID. If the length of the user ID is made configurable and random.SystemRandom().choice is used instead, it should act as a reasonably secure key when used programmatically.