Authentication

[AnalogJ]

Basic auth?

[bergernetch]

Basic Auth is ok for quick and dirty. Better would be something like

• Form based authentication

• JSON Web Tokens - jwt.io

[AnalogJ]

TBH, I was debating if auth is even necessary, since Srutiny is designed to be read-only. I'm sure there's going to be people interested in authentication, but it'll probably be a low priority, unless there's a use-case I'm missing.

[davispuh]

Can't it be just placed behind reverse proxy like Nginx? Then for Nginx you can use plugin like https://github.com/zmartzone/lua-resty-openidc and you get support for all OpenID auth providers for free, such as Google and so on. Can even host your own auth server with LDAP support.

[maran]

Just came in to 👍 some form authentication. I wanted to collect harddisk data over a cluster of servers and even though it's read-only I still feel that my cluster should not be public information. Basic Auth would be fine as a start as it's quite easy to implement and will probably cover most use-cases.

[jakob42]

TBH, I was debating if auth is even necessary, since Srutiny is designed to be read-only. I'm sure there's going to be people interested in authentication, but it'll probably be a low priority, unless there's a use-case I'm missing.

I think it's not scrutinys job, let the webserver or an auth layer like authelia handle it. But I disagree in regards of read only. In case somebody breaks into the container due to a vulnerability in the webinterface, AFAIU they have complete access to my /dev/sdx's, don't they?

[joe-eklund]

Figured I would let you know how I accomplished authentication. I am using Traefik + Organizr. I use Traefik forward auth so that it only lets you view Scrutiny if the user logged in has the proper access level.

This way I can protect Scrutiny from the outside world and normal users, yet still let admins have access to it when authenticated properly. Works really well actually.

[davispuh]

Traefik is basically reverse proxy so yup same as my Nginx suggestion. Nice that it works well so we don't really need anything else :)

[almereyda]

It would be easy to place an OAuth2 Proxy inbetween the application, and a TLS-terminating edge proxy.

Self-managed OAuth2/OpenID Connect providers could be used.

[NemesisRE]

As there is no user management there is no need for oauth2/openid support basic auth would be an option but if you really need an authentication system just proxy one in front of it, I use SWAG and goauthentik.io. Other proxy servers work too and other authentication providers like keycloak would be another option or even simple solutions like authelia would work easily.

[AnalogJ]

stavros-k wrote:

Is your feature request related to a problem? Please describe. I want to have remote machines post metrics on my scrutiny server. Currently anyone with my URL can do that.

Describe the solution you'd like I'd like to able to have an API token, so server will only accept metrics from a client that provides the correct token.

Additional context It would be nice to have multiple tokens, so you can revoke any compromised. But also supporting 1 token would be ok (considering there isn't any now)

[NSGrid]

And let me ask you, what is the login screen that appears when you try to open scrutiny docker container on port 8086? It says influxDB and below it there are fields for entering login and password. And if I set the login and password as variables in the compose.yaml file, then nothing happens, these logins and passwords are not accepted. :

environment:
      - SCRUTINY_WEB_INFLUXDB_TOKEN=ANYLONGSTRING
      - SCRUTINY_WEB_INFLUXDB_INIT_USERNAME=Login
      - SCRUTINY_WEB_INFLUXDB_INIT_PASSWORD=Password

Is it possible to understand what credentials are there and what they are needed for?

[AnalogJ]

Hey @NSGrid have you taken a look at the Influx DB related documentation? It describes why influxdb is needed, and how it is configured.

https://github.com/AnalogJ/scrutiny/blob/master/docs/TROUBLESHOOTING_INFLUXDB.md

The part that might be relevent here is:

During first startup Scrutiny will connect to the unprotected InfluxDB server, start the setup process (via API) using a username and password of admin:password12345 and then create an API token of scrutiny-default-admin-token.

Basically the username and password is only used for first auth, after that Scrutiny just uses the API token. Changing the env variables after the initial setup won't do anything.

---

This issue is related to adding an authentication mechanism to Scrutiny, so if you have more questions about InfluxDB, you'll want to open a new issue.

[arpanghosh8453]

Does the API endpoint /opt/scrutiny/bin/scrutiny-collector-metrics run --api-endpoint "http://external-web-ui-address:port" support basic authentication passing so that I can use it with my reverse proxy?

[dudeofawesome]

I can confirm that it does. I'm currently using it with my remote collector setup.

I ended up creating 2 reverse proxy entrypoints, one for the API using basic auth, and another for the dashboard & API, using forward auth.

[arpanghosh8453]

@dudeofawesome Please share how you have done the setup :)

[dudeofawesome]

All you need to do is setup your reverse proxy to require basic auth (I'm using Traefik), and then set your collector's api-endpoint to include the basic auth credentials. Something like scrutiny-collector-metrics run --api-endpoint "https://username:password@scrutiny-api.example.com"

[arpanghosh8453]

Thank you @dudeofawesome That worked perfectly. I was just looking for this "https://username:password@scrutiny-api.example.com" syntax 👍

[pedoc]

+1 for this Although it can be achieved using reverse proxy tools such as nginx or Traefik, it is not easy. It would be nice if it was supported by default

[Tuxdude]

I think there are two things here:

1. Configuring basic auth in the Web UI to view the data (read-only)
2. Configuring basic auth in the Web UI for collectors (in the hub and spoke model) to publish the data (write)

It is now the norm for most self hosted services to not solve the auth problem and leave this to other layers above. Also, configuring basic auth / OAuth / etc. as a whole is fairly trivial if you have some form of reverse proxy (nginx, caddy, etc.).

However, things change slightly in the hub and spoke model where you have a client which is pushing data to the server. I wouldn't leave this one unprotected. Having some form of auth/token mechanism would be the best practice recommendation here. Yes, if you have a reverse proxy configuring basic auth is trivial and hence I don't mind going that route (which I use for many other self hosted services as well).

However, I feel there is no documentation pointing to how to set up basic auth on the collector (and the comment from https://github.com/AnalogJ/scrutiny/issues/34#issuecomment-1969924306 was my solution). I feel the documentation could be updated to describe this so that we don't have to search through this issue thread and comments to figure out the solution :)

[AnalogJ]

@Tuxdude That's fair. I'd be open to a authentication guide in the docs/ folder. Would you be willing to contribute that via a PR?

[kapsh]

+1, anybody working on this? Reverse proxy can be workaround, but first party auth is a must. Scrutiny has destructive actions (removing disk history) which shouldn't be available to everyone.