Configuration endpoint

[jvehent]

In a few cases, we have implemented endpoints that expose the configuration of a running app. I think it would be useful to standardize how to do that, and document it as optional.

A few considerations:

• Expose ENV variables as key/value under an environment key ?
• Expose hard-coded config under configuration key ?
• Limit exposure to internal network and/or authenticated endpoints only (simple token should be enough)?
• Use the standard __config__ endpoint?

[hwine]

Do we have any data on usage of these endpoints?

Do we understand the (perceived or actual) benefit to devs and ops of the endpoints?

[g-k]

Expose ENV variables as key/value under an environment key ?

Could be useful, would want to

Expose hard-coded config under configuration key ?

What would this look like?

Limit exposure to internal network and/or authenticated endpoints only (simple token should be enough)?

Definitely would be useful from a scanning and testing perspective e.g. should be accessible, should require VPN, SSO, etc. Could also be project or server level tags.

Use the standard config endpoint?

Haven't heard of this.

In general, it'd be good to have apps report more of their behavior assuming implementation cost is low and it doesn't expose anything sensitive.

[hwine]

Expose ENV variables as key/value under an environment key ?

This feels dangerous, as lots of secrets are in env variables. We may want to consider recommending implementation similar to Apache Airflow where certain key patterns are "un viewable".

[jvehent]

Right, we probably don't want to grab everything by default, but instead recommend a standard way to expose configuration should that be needed, and warn about exposing secrets.