support tls (with InsecureSkipVerify)

[soulware]

Support tls via case on FluentNetwork - tcp|tls|unix

[tagomoris]

@soulware How did you check this patch works?

[soulware]

Hey @tagomoris - planning on working on getting some test coverage for this over the next couple of days. Wanted to get this on your radar early.

[tagomoris]

Ah, I meant about the major use-case of this feature.
We need a kind of destination - what is that in your idea?

[soulware]

If I understand your question correctly - we are intending to run fluentd with in_secure_forward plugin installed.
And host and port would be configured as necessary.
Maybe I'm not understanding your question?

[tagomoris]

I think you understood my question. Thank you to answer for me.
And, currently, in_secure_forward requires handshake phase before transferring data, in addition to SSL/TLS transportation. Fluent logger libraries (there's no implementation which can do handshake) cannot send events to it.

[tagomoris]

Fluentd v0.14 will have feature updates to use SSL/TLS transport layer with or without handshake protocol... now v0.14.6 has handshake(authentication) feature, but only on raw TCP.
This feature (sending events over SSL/TLS without handshake) will be useful with such coming version of Fluentd, but there's (almost) no configuration/implementation available with this feature right now.

[soulware]

Interesting - thanks for the info.
Alternatively we could potentially terminate SSL/TLS at the Load Balancer in AWS and use TCP from Load Balancer to Fluentd.
If we do it this way then this change to the logger would have value today?

[tagomoris]

Correct. It's the reason of (almost) in my comment, and the original meaning of my first question: "did you confirm this patch works well with SSL terminator & in_forward?"

[soulware]

I'm confused by "v0.14 will have feature updates" when v0.14.6 is out now. Do you mean v0.15?
Wondering if this approach is something that is still worth pursuing or if we need to rethink our approach (in terms of how we use the client logger).

[tagomoris]

I'll introduce it in any version of v0.14.x (7 or 8).
This change looks good to push, but might be good to merge after the
release of Fluentd with SSL support.

2016年9月29日木曜日、Simon [email protected]さんは書きました:

I'm confused by "v0.14 will have feature updates" when v0.14.6 is out now.
Do you mean v0.15?
Wondering if this approach is something that is still worth pursuing or if
we need to rethink our approach (in terms of how we use the client logger).

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#37 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAOE_npX79lpASns6FDb0suy5GcyuV8Zks5qur5zgaJpZM4KICdv
.

田籠 聡 (TAGOMORI Satoshi)
Mail: [email protected]

[meirwah]

Is this PR still alive?

[sanbornm]

This PR doesn't work as is.

This line:

f.conn, err = tls.DialWithDialer(dialer, f.Config.FluentNetwork,
f.Config.FluentHost+":"+strconv.Itoa(f.Config.FluentPort),config)

Should be:

f.conn, err = tls.DialWithDialer(dialer, "tcp",
f.Config.FluentHost+":"+strconv.Itoa(f.Config.FluentPort),config)

[wfernandes]

We have a need to support Fluent-bit Forward protocol via TLS. I see that the Forward Protocol for fluentd supports mutual TLS.

Or is there another golang library that supports TLS over the Forward Protocol?

Thanks.

[Manikandan-Raj]

@wfernandes , Did you find any golang library for forwarding which supports TLS ???

[wfernandes]

@Manikandan-Raj We didn't. Instead we used ghostunnel as a TLS proxy between our source and fluent-bit.

[jeremy-ebler-vineti]

In 2016, there wasn't TLS support in fluentd, but today in_tcp supports native TLS.

https://docs.fluentd.org/input/tcp#less-than-transport-greater-than-section

[zonito]

@fujimotos / @tagomoris we can close this as well. #107