On 29 May 20:11, Brian Brazil wrote: > On Fri, 29 May 2020 at 19:49, Julien Pivotto <[email protected]> > wrote: > > > > > Dear developers, > > > > As we will generalize the TLS code in the coming months in the project, > > I would like to see if there is we can reach consensus in the following > > topic: > > > > - The exporters should not offer a way to visualize the TLS config in the > > Web UI, as that would expose unneedlessly things like usernames. > > - The prometheus/AM UI's should not offer a way to visualize the TLS config > > in the > > Web UI. > > > > I don't agree with this, we already have mechanisms to hide secrets in UIs > and usernames are not secrets. We already expose usernames in our UIs. > I think that if an application wishes to expose this we shouldn't > prevent that, we should treat it as we would any other config file. How > that'd work in implementation terms is another question. > I don't think exporters should be forced to expose this though, as many of > them don't have UIs to speak of.
Mmmh yes now that you say that: if you *set* usernames, you will have to be logged in to see the username. So indeed, that does not seem an issue as they would not be visible to non-logged in users. To the Node Exporter maintainers: do you want a /config endpoint with this? > > - In prometheus, the web tls config should be a second config file, not > > included in the main file, because it is unmarshalled upon each HTTP > > request > > and some config files are pretty huge. > > > > I think this is the only sane way to do this, with the possible > complication of Alertmanager clustering. > > > > - As we plan to make the TLS config reusable, it could somehow be > > versioned or included "on its own" in the docs, and that could start now > > already. The exporters and prometheus config would point to that > > dedicate space in the docs. > > > > That seems reasonable, I'd go for its own. A page under Operating would be > my first thought, which also happens to be beside the security model. Do we want to version it? And how could we version it? I know some software (open distro for elasticsearch) use a "schema version" in the yaml: https://opendistro.github.io/for-elasticsearch-docs/docs/security-configuration/yaml/ _meta: type: "internalusers" config_version: 2 And id the version does not match your version, you need to adapt the config. What do you think of an approach like this? the error message would be along the lines: TLS configuration version 3 is required, found 2. Please check https://prometheus.io/blah to upgrade. > > Brian > > > > > > > > What do you think? > > > > -- > > Julien Pivotto > > @roidelapluie > > > > -- > > You received this message because you are subscribed to the Google Groups > > "Prometheus Developers" group. > > To unsubscribe from this group and stop receiving emails from it, send an > > email to [email protected]. > > To view this discussion on the web visit > > https://groups.google.com/d/msgid/prometheus-developers/20200529184904.GA47231%40oxygen > > . > > > > > -- > Brian Brazil > www.robustperception.io > > -- > You received this message because you are subscribed to the Google Groups > "Prometheus Developers" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/prometheus-developers/CAHJKeLqEVmasYz6HsCVukKdMOFQkZ_j%2Bjiji5oCL3i%2BPci9c_g%40mail.gmail.com. -- Julien Pivotto @roidelapluie -- You received this message because you are subscribed to the Google Groups "Prometheus Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/prometheus-developers/20200529192019.GA127282%40oxygen.
