Offer two options for access model

[krancour]

We've seen that the admin user can do things we might not want them to do-- like delete the dashboard that we're pre-provisioning. This means we should want most users (if not all) to only be viewers.

If an operator wants to deploy brigade-prometheus and take on responsibility of administering Grafana, then they can create user accounts for others with lesser permissions (e.g. view-only). This puts the onus of managing the system responsibly on just one privileged user and that seems reasonable. If they do something stupid like deleting the dashboard-- that's on them-- and they presumably will know how to fix that by re-installing.

Not everyone will want to take this approach.

The threat model here doesn't suggest that these metrics are high value data, and as such, I'd propose that opting into a shared username/password would be acceptable as long as the shared "account" isn't an admin.

I want to propose offering two options to the operator who installs this software:

1. Option to specify admin username/password in values.yaml and onus for Grafana user management falls to the operator.

2. Option to specify a shared username/password in values.yaml. Grafana doesn't have a way of pre-provisioning users, so the way this would have to work is that we'd enable anonymous view access on Grafana itself, then use Nginx as a reverse proxy (probably in a sidecar container) to enforce basic auth.

[willie-yao]

This has been implemented in #6 , closing the issue now.