Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Passing Bearer token when connecting to remote workspace #1152

Open
m-blasiak opened this issue Jun 12, 2024 · 2 comments
Open

Passing Bearer token when connecting to remote workspace #1152

m-blasiak opened this issue Jun 12, 2024 · 2 comments

Comments

@m-blasiak
Copy link

I am trying to setup a self hosted ML monitoring with Evidently.

I have Evidently running inside a container on a remote host. The host requires an Authorization header with a Bearer token.

According to the documentation, passing a secret is possible via:

However, it looks like Evidently passes the secret value as evidently-secret header instead of an Authorization header. (see here and here)

Would it be possible to allow users to specify the name of the header the secret should be attached to?

@DimaAmega
Copy link
Collaborator

Hi

We are using "evidently-secret" header in order to protect write api. You should never use this functionality for authorization.

But, of course, you can have your own proxy authorization layer just before running "evidently ui" (i think modifying evidently source code is bad idea for your purposes). This layer just check token, if ok - proxy request to running "evidently ui" server

Is it helpful for you?

@m-blasiak
Copy link
Author

Thanks for the reply @DimaAmega, perhaps the Documentation on this could be clarified a little bit. Right now it simply states:
image

It is a bit ambiguous and I initially assumed this was basically the auth token required to access the remote server. MLFlow has done something similar (see https://mlflow.org/docs/latest/auth/index.html#using-environment-variables).

I understand this is unfortunately not possible with Evidently. We can work around it and secure the service in a different way, but more clarity in the documentation would be appreciated.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants