Allow auth to accept API keys

[saiatmakuri]

first step in API key migration - chain functions tried

[seanshi-scale]

I'm not super confident we should be exposing notions e.g. user id + api key for the public repo, e.g. this functionality may belong better somewhere else (e.g. model-engine-internal)

[yixu34]

I'm not super confident we should be exposing notions e.g. user id + api key for the public repo, e.g. this functionality may belong better somewhere else (e.g. model-engine-internal)

Hmm I suppose that may be true. If we're hosting internally, we don't need to mention API keys here because the rest of our stack handles that; if we're deploying in customer VPCs, we rely on them to manage API keys and auth.

The main difference is that the EGP APIs do need to do this, because they're more of a fully fledged platform product that needs to manage its own API keys. cc @eric-scale

[saiatmakuri]

I'm not super confident we should be exposing notions e.g. user id + api key for the public repo, e.g. this functionality may belong better somewhere else (e.g. model-engine-internal)

I guess that I'm just acknowledging the underlying auth_repo functions here more loudly. That is, we currently use auth_repo.get_auth_from_user_id_async and now I'm referencing auth_repo.get_auth_from_api_key_async in a separate routine. The final steady state will be to only use the latter method with api keys. I believe we can introduce a new notion of UserRepo that can perform authentication via API keys. However, I think we defer this abstraction to a later time.

[yixu34]

【ｗｅ　ｌｏｖｅ　ｄｅｐｅｎｄｅｎｃｙ　ｉｎｊｅｃｔｉｏｎ】

[seanshi-scale]

did this file get moved to internal?

[yixu34]

I suppose that dependencies on public vendors (e.g. Datadog) can be put in our public repo. It's the Scale-specific bits that need to be internal.

[saiatmakuri]

yup, now a plugin