Prompt the user to create a password for accessing Grafana at install-time

[velovix]

This password will be stored to the .env file and used by BrainFrame's docker-compose.yml. This improves security as it prevents Grafana's default admin user from ever being publicly accessible.

[velovix]

Grafana's login page could potentially be removed if we add a global log-in screen for all BrainFrame services.

[apockill]

Would we prompt for passwords for each service, or ask for a generic password and apply it to all the things? (Our customers might not know what Grafana is for example).

Please set a password for the BrainFrame services:
> 

might yield a .env with

GRAFANA_PASSWORD=hunter2
POSTGRES_PASSWORD=hunter2
OTHER_SERVICE_AUTH=hunter2

---

I'm probably overthinking this though. Do we even need more than one password at the moment?

[apockill]

Grafana's login page could potentially be removed if we add a global log-in screen for all BrainFrame services.

Would we have to modify grafana's source for that? I think that may violate their AGPL license

[BryceBeagle]

Looks like you can configure the Grafana username/password through configuration files

https://grafana.com/docs/grafana/latest/administration/configure-docker/#configure-grafana-with-docker-secrets

[apockill]

@BryceBeagle Tyler is talking about a longer-term goal to have a separate service be our "log in" authenticator for all services in BrainFrame. I think that having grafana use our service for the login page may require a bit of code change with Grafana.

[BryceBeagle]

Couldn't we do something fancy with nginx? If not authenticated, serve a different image with a login screen. If authenticated, serve the grafana image.

[velovix]

Grafana has some support for delegating authorization to another service. I haven't looked into it too much though.

[velovix]

I think at this point it's clear that we need a shared authorization service that lives on top of all of our other services. We would then want to turn off Grafana's authorization since it's redundant. Closing in favor of #30.