Closed Mexx77 closed 6 years ago
the only modern relay that supports upstream Metrics 2.0 and GrafanaNet
this traffic uses https.
Nevertheless, native SSL support for incoming TCP would be much nicer. Is it hard to add support for encrypted ingress traffic?
afaik the official graphite / carbon protocol has no provision for ssl. perhaps 3rd party utilities are doing it somehow, not sure how that should integrate with the ecosystem though. can you provide links to existing implementations?
I'm using https://github.com/jamiealquiza/polymur to ship our old carbon receivers -> across cloud account -> Metrictank. Its another option but if you can use tsdb-gw + metrictank i'd go with that instead. Metrictank is really the way to go moving foward. If your auditors are a real pain you could sidecar polymur-proxy ship to a sendoff point with tsdb-gw, im assuming clear text to 127.0.0.1:2003 would be alright. I think what the whole community really needs are better libraries from the hosts. Dropwizard graphite output to kinesis/kafka directly or even an https metrics output acceptor.
@Dieterbe I know it uses https. https://github.com/grobian/carbon-c-relay seems to have an SSL option implemented. For now, I SSL-terminate with an nginx in front, which passes plain TCP on to carbon-relay-ng
https://en.wikipedia.org/wiki/Transport_Layer_Security says
Transport Layer Security (TLS) – and its predecessor, Secure Sockets Layer (SSL), which is now prohibited from use by the Internet Engineering Task Force (IETF)
:/
basically i'm trying to find what's the best practice here, as i'm not well versed in ssl/tls stuff.
the predecessor, Secure Sockets Layer (SSL), is "prohibited". Not TLS! (thats how I read the sentence). This seems to be the official TLS package: https://golang.org/pkg/crypto/tls/. And here is an example: https://gist.github.com/spikebike/2232102
But sure, to implement it properly, you need time...
that's also how i read it, but it looks like carbon-c-relay implements ssl, not tls. though i haven't dived into the code yet
the phrase "ssl" is often used when actually "tls" is meant. For example in ssl-termination (when we actually terminate a TLS connection).
I am using an nginx for now.
At my company I am facing a cloud compliance constraint, requiring every communication to be encrypted. I'd like to use carbon-relay-ng as it seams to be the only modern relay that supports upstream Metrics 2.0 and GrafanaNet. However, I cannot use it without the support of SSL/TLS termination. I will probably go and setup an nginx as a SSL termination proxy in front.
Nevertheless, native SSL support for incoming TCP would be much nicer. Is it hard to add support for encrypted ingress traffic? The old carbon-c-relay hat such a config parameter, I believe.
I could try to implement it myself. Not sure where to start though. Could you point me to the location in the source code?