Always require OTLP auth mode config when starting dashboard

[JamesNK]

Require OTLP auth mode when starting the dashboard so users must make an explicit decision to have no auth.

@davidfowl FYI, this was review feedback.

Microsoft Reviewers: Open in CodeFlow

[JamesNK]

TODO: update standalone dashboard docs and sample

[davidfowl]

Instead of throwing, can we make it show a page that shows the error and explains what to do?

[JamesNK]

It's possible, but it would be a lot more work. We'd need to make the new UI. And since the app is starting up in an invalid state, we'd need put checks throughout the app to disable all the other UI and functionality, e.g. ignore incoming OTLP data, don't allow visiting regular UI, hide links to regular UI, don't watch for resources, etc.

[JamesNK]

Since there is auth for OTLP and auth for the browser, and each has different config settings, it would be annoying to have to explicitly set both to None.

Maybe there should be a config setting such as DOTNET_DASHBOARD_ALLOW_ANONYMOUS that defaults the modes to none. Requiring one parameter is better than two.

What do you think @drewnoakes @davidfowl?

[drewnoakes]

There are security considerations in having single variable to opt out for all security features. If we add new kinds of security in future, should users that opted out before be automatically opted out of the new security too? The user may have reviewed the decision during installation. They may wish to review newer features as well.

If we are going to have a single variable, its name should evoke considerable caution. Something stronger than DOTNET_DASHBOARD_ALLOW_ANONYMOUS. Perhaps INSECURE_DOTNET_DASHBOARD_DISABLE_AUTH.

[JamesNK]

There are security considerations in having single variable to opt out for all security features. If we add new kinds of security in future, should users that opted out before be automatically opted out of the new security too? The user may have reviewed the decision during installation. They may wish to review newer features as well.

If we are going to have a single variable, its name should evoke considerable caution. Something stronger than DOTNET_DASHBOARD_ALLOW_ANONYMOUS. Perhaps INSECURE_DOTNET_DASHBOARD_DISABLE_AUTH.

It's not opting out of all security features, just dashboard endpoint authentication. For example, it wouldn't disable configured HTTP security between the dashboard and resource service.

What about DOTNET_DASHBOARD_INSECURE_ALLOW_ANONYMOUS? That keeps DOTNET at the front, similar to other .NET environment variables. Kind of long though.