Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add tls support for exporters #142

Closed
bputt opened this issue Jun 20, 2019 · 8 comments
Closed

Add tls support for exporters #142

bputt opened this issue Jun 20, 2019 · 8 comments
Labels
area:sdk Related to the SDK needs discussion Need more information before all suitable labels can be applied
Milestone

Comments

@bputt
Copy link

bputt commented Jun 20, 2019

We've extended opencensus to use tls for zipkin exporter and imagine it would be helpful to others if tls was an option for all exporters.

Should the spec include TLS for exporting? I know this doesn't matter for certain cloud providers, but for non-cloud native environments, it's required (whether we setup a local proxy that adds tls or if the exporter supported it out of the box (which would be ideal))

@SergeyKanzhelev
Copy link
Member

What does TLS stands for in this context?

@SergeyKanzhelev SergeyKanzhelev added this to the API revision: 07-2019 milestone Jun 20, 2019
@bputt
Copy link
Author

bputt commented Jun 20, 2019

@SergeyKanzhelev for example, the zipkin exporter, it doesn't have an option to pass in an SSLContext where we could send the data to an https endpoint.

@flands
Copy link

flands commented Jun 21, 2019

@bputt whether an exporter supports TLS or not is up to the exporter. Agreed, depending on the configuration, TLS may be a requirement. Some exporters, such as the opencensus exporter, support TLS today. Is the purpose of this issue to standard the configuration parameters for TLS in an exporter?

@bputt
Copy link
Author

bputt commented Jun 21, 2019

@flands Yes, have some standardization that allows TLS to be put into place within an exporter

@flands
Copy link

flands commented Jun 21, 2019

Got it -- to that end, there are multiple common parameters that exporters should standardize on beyond TLS. Some common ones today:

            compression: "gzip"
            endpoint: "foo.bar:443"
            headers: {"foo":"bar"}
            num-workers: 8
            reconnection-delay: 2s
            secure: true

Today, secure: true enables TLS -- the key/value can be debated.

@SergeyKanzhelev is the point of the specification for API definition only? If so, where should receiver/exporter standards live? If not, I will create a section for receivers and exporters and put up a PR.

@SergeyKanzhelev
Copy link
Member

@flands that was the first iteration. The intention to specify SDK as well. This set of settings is a good one.

@tedsuo tedsuo added the area:sdk Related to the SDK label Jul 11, 2019
@bputt
Copy link
Author

bputt commented Jul 16, 2019

@SergeyKanzhelev @flands Not sure if it was implied or not, but if I added secure: true I would also want to provide a cert, key, and cabundle

@iredelmeier iredelmeier added the needs discussion Need more information before all suitable labels can be applied label Jul 30, 2019
@SergeyKanzhelev SergeyKanzhelev removed this from the API revision: 07-2019 milestone Sep 27, 2019
@bogdandrutu bogdandrutu added this to the Alpha v0.4 milestone Sep 30, 2019
@jmacd
Copy link
Contributor

jmacd commented Jan 22, 2020

Closing this -- it's uncontroversial that we will support secure transport for TCP connections.

@jmacd jmacd closed this as completed Jan 22, 2020
@bogdandrutu bogdandrutu modified the milestones: v0.5, v0.4 May 12, 2020
TuckTuckFloof pushed a commit to TuckTuckFloof/opentelemetry-specification that referenced this issue Oct 15, 2020
rockb1017 pushed a commit to rockb1017/opentelemetry-specification that referenced this issue Nov 18, 2021
Update changelog with complete change since 1.0.0.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area:sdk Related to the SDK needs discussion Need more information before all suitable labels can be applied
Projects
None yet
Development

No branches or pull requests

7 participants