8000 Configuration endpoint · Issue #56 · mozilla-services/Dockerflow · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

Configuration endpoint #56

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Open
jvehent opened this issue Jul 9, 2020 · 4 comments
Open

Configuration endpoint #56

jvehent opened this issue Jul 9, 2020 · 4 comments

Comments

@jvehent
Copy link
Contributor
jvehent commented Jul 9, 2020

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
Copy link
hwine commented Jul 9, 2020

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
Copy link
g-k commented Jul 9, 2020

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
Copy link
hwine commented Jul 9, 2020

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
Copy link
Contributor Author
jvehent commented Jul 9, 2020

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@hwine @g-k @jvehent
0