Open saroshali-dbx opened 2 years ago
Hi! This issue has been automatically marked as stale because it has not had any activity in the past 30 days.
We use a stalebot among other tools to help manage the state of issues in this project. A stalebot can be very useful in closing issues in a number of cases; the most common is closing issues or PRs where the original reporter has not responded.
Stalebots are also emotionless and cruel and can close issues which are still very relevant.
If this issue is important to you, please add a comment to keep it open. More importantly, please add a thumbs-up to the original issue entry.
We regularly sort for closed issues which have a stale
label sorted by thumbs up.
We may also:
revivable
if we think it's a valid issue but isn't something we are likely
to prioritize in the future (the issue will still remain closed).keepalive
label to silence the stalebot if the issue is very common/popular/important.We are doing our best to respond, organize, and prioritize all issues but it can be a challenging task, our sincere apologies if you find yourself at the mercy of the stalebot.
Is your feature request related to a problem? Please describe. Currently when using TLS, Loki will accept requests from any client that has a certificate signed by our Certificate Authority. For enforcing the deny-by-default security requirement, we need to check the common name against the expected value and reject requests that do not match. As such, I'd like to see custom server certificate validation supported as part of Loki.
Describe the solution you'd like I'd like to be able to pass a flag to loki, such as
-cert-allowed-cn
, that can be used to create a customVerifyPeerCertificate
function as part of the crypto/tls package. All this function needs to do is verify that the seen common-name is the same as the expected common-name.Describe alternatives you've considered Within our organization, we (ab)use custom gRPC certs signed from a custom authoritative root CA. If we wanted this behavior to work without any changes to Loki we'd have to create a separate set of certificates signed by another root CA. Managing and securing CAs is already hard enough, so we'd prefer to not have to add another one.
Additional context I noticed that the gRPC/HTTP server implementations for loki are lifted fromhttps://github.com/weaveworks/common/blob/master/server/server.go, likely a new parameter would need to tunneled and implemented there.
I'm willing to attempt an implementation if Loki maintainers think this is a good idea.