Add an endpoint that will output Athens configuration

[arschles]

Is your feature request related to a problem? Please describe.

Athens has many configuration values and it's easy to get them mixed up. We are taking several measures to make it easier to make sure you don't configure it with anything obviously bad.

Describe the solution you'd like

Along with other strategies to make this better, it would be helpful to opt-in to an HTTP endpoint that an operator can curl and that outputs the current configuration. That would be helpful to help with debugging.

Describe alternatives you've considered

We could have Athens log everything on startup.

Additional context

N/A

[fedepaol]

Hey, can I work on this?

[arschles]

@fedepaol absolutely! 💚

[marwan-at-work]

This feature sounds very helpful 💯

However, we should make sure it is protected because the configuration might have sensitive information like credentials to access storage.

[fedepaol]

Ah you are right @marwan-at-work .
I was thinking about integrating https://golang.org/pkg/expvar/ instead of doing a custom solution, but not sure it fits the bill of having the endpoint protected.
One thing we can do is to obscure the sensitive fields (those related to auth) before exporting the configuration. Another one is to expose such endpoint under basic auth.

Thoughts?

[arschles]

I don't think basic auth is worth it personally. I'd rather put the endpoint behind a configuration value that defaults to off. If someone wanted to turn it on, they would need to use their firewall/load balancer/etc... to protect it for now. If the endpoint gets widely used, I'd then advocate for supporting Authorization header based auth. All a strong opinion weakly held. What do you think?

[fedepaol]

Make sense to me.
If we foresee using auth, it's still probably worth using a custom endpoint instead of expar.

[marwan-at-work]

If auth is not worth it for now, here are the options I can think of (and were mentioned above):

Option 1: I like the idea of obscuring sensitive fields. But we should make sure the implementation is easy to maintain, maybe any sensitive configuration would implement the fmt.Stringer interface.

Option 2: a configuration option to either output everything or not output everything.

Option 3: expose the endpoint on a different port, this will mean only those who can access the Athens machine/container can ping that endpoint.

[arschles]

My vote is for (1) and (3). I personally would like to set CONFIG_OUTPUT=true and CONFIG_PORT=9090 and automatically have all non-sensitive data get output on port 9090.

[marwan-at-work]

I think if we do CONFIG_OUTPUT and CONFIG_PORT, at that point I feel comfortable exposing sensitive data because it's not reachable on the Athens default server.

That said, we can implement 3 first and then implement 1 as an enhancement after...but maybe users would want to see everything especially the sensitive configuration to debug auth issues. In that case we could have a ABSTRACT_SENSITIVE_FIELDS configuration, which would also suggest that we should nest those 3 fields into a ExposeConfig object 😄