Add TLS and basic auth policy

[roidelapluie]

All of this comes from the dev summit 2018 notes:

https://docs.google.com/document/d/1-C5PycocOZEVIPrmM1hn8fBelShqtqiAmFptoG4yK70/edit#

cc @RichiH @juliusv @brian-brazil @SuperQ

[gouthamve]

LGTM!

[brian-brazil]

Thanks for this.

[roidelapluie]

Added a note about security of the config file, too

[brian-brazil]

Hmm, this is the first mention of a configuration file which makes it seem as though we forgot that - though I don't think we need this level of detail in this doc (that's more for the usage docs).

[roidelapluie]

that config file has security implications -- if people give access to anyone it is possible to change certs, disable client side auth, add users..

[brian-brazil]

What goes in what config files is too detailed to go here I think, plus other config files also have security implications depending on your setup.

[brian-brazil]

This still needs a justification of some form, this appears completely arbitrary currently which will make it more challenging to deal with requests to change it good/bad reasons.

[roidelapluie]

I have added links.

[brian-brazil]

That's a good start, we need something to cover why we're not changing anything else - otherwise we could have fun when any of those 4 organisations propose e.g. going to TLS 1.3 only or disabling specific ciphers. For example the current standing policy is to stick to the Go defaults, so that the decision is completely out of our hands and we thus can keep it simple and not worry about any of this.

What I'm looking for here (and have been asking for in relation to TLS&friends for many years) is essentially a plan that doesn't boil down to making it up as we go along. There's various hurdles we will inevitably have to deal with as things naturally evolve over time, and I don't want us to have a half-baked approach to TLS that considers the feature done and dusted merely because some code has been written. The code is the easy bit, and a justification that only covers why we have these particular settings right now is not enough. Users requesting changes to the hard coding, vulnerabilities, increases in computing power, geopolitics, changes in dependencies, and new standards are all going to happen.
The policy needs to be able to help answer questions like when we would disable 1.2, reenable 1.0 (and yes, it has happened in the past that an older version was suddenly more secure than a newer version), switch to/from whatever the cipher flavour of the month is, and what happens when Go changes their defaults. So things to be considered might include how much breakage of existing users is okay, is it okay to create a situation where the latest releases of official Prometheus components don't work with each other, how far back are we willing to have such breakage, how perfect should our ssllabs rating be, how good the actual security is for typical users, how often we need to reevaluate/update this configuration, how much effort we're realistically able/willing to put into this, and how we try to balance all these concerns.

Now all of that doesn't belong in this document as this document is more a what than why, but if you want to have a consensus to change our policy to one that allows for TLS 1.0/1.1 to be disabled then this needs to exist in some form.

[roidelapluie]

"We strive to keep TLS
compatibility with official client libraries
runtimes that were released less than two years ago."

[brian-brazil]

Doing some research Go was the last to release TLS 1.3 support in February 2019, so 2 years means we would drop 1.2 support in February 2021.

[roidelapluie]

Added:

"We strive to keep TLS
compatibility with official client libraries
runtimes that were released less than two years ago."

[SuperQ]

LGTM

[brian-brazil]

client library runtimes

This still isn't covering all the other settings

[brian-brazil]

on disk

[roidelapluie]

To lift some of the concerns about what we can and can't accept as contributions from users, and I think that whatever we write here we will get those questions, I proposed the following pull request in the node_export https package, covering a wider range of TLS settings that can be set:
prometheus/node_exporter#1695

That way we enable users to pick their TLS settings.

[brian-brazil]

I think that level of change would require a dev summit discussion, as any configurability was seen as off the table at the last one - particularly as that PR has made some interesting choices in what it does and doesn't allow to be configured.

[SuperQ]

@brian-brazil We do not require dev summits for making decisions. A dev summit is simply a way to get the same lazy consensus and/or vote done in real time.

[brian-brazil]

You're correct, however given all the back and forth on this issue a dev summit would seem the most expedient way of moving from the standing plan of pure defaults to anything else.

[brian-brazil]

👍

[brian-brazil]

Go

[juliusv]

I'd either say "node_exporter" or "Node Exporter" (probably the latter in a normal English sentence), but mixing snake_case with CamelCase seems odd (same for Blackbox Exporter).

[roidelapluie]

ack

[juliusv]

Suggested change

	cipher are not [marked as insecure](https://golang.org/pkg/crypto/tls/#InsecureCipherSuites)
	cipher is not [marked as insecure](https://golang.org/pkg/crypto/tls/#InsecureCipherSuites)

[roidelapluie]

ack

[juliusv]

👍 besides editorial nits

[roidelapluie]

Thanks all!