Error loading TLS certificates from ENV variable #10405
Labels
Comments
|
From the Slack convo, we confirmed the issue also happens with the |
|
i experience exactly the same issue on version 0.104.0 |
|
@k15r can you reproduce with 0.103.0? |
|
I used the exact same configuration with a freshly built |
|
@k15r I think this issue is not related to your problem then. Could you try running v0.104.0 but passing the
|
|
No complaints when i disable the feature. I assume the new feature broke the parsing of newlines in the PEM block. |
Hm, I don't think the changes we made here would affect newlines there, can you share your configuration? (without the PEM block or any other identifying details of course 😄) |
|
here you go: service:
pipelines:
traces/traces-mtls-missing-values--missing-all:
receivers:
- otlp
processors:
- batch
exporters:
- otlp/traces-mtls-missing-values--missing-all
traces/traces-mtls-missing-values--missing-all-but-ca:
receivers:
- otlp
processors:
- batch
exporters:
- otlp/traces-mtls-missing-values--missing-all-but-ca
traces/traces-mtls-missing-values--missing-ca:
receivers:
- otlp
processors:
- batch
exporters:
- otlp/traces-mtls-missing-values--missing-ca
telemetry:
metrics:
address: ${MY_POD_IP}:8888
logs:
level: debug
encoding: json
receivers:
otlp:
protocols:
http:
endpoint: ${MY_POD_IP}:4318
grpc:
endpoint: ${MY_POD_IP}:4317
processors:
batch:
send_batch_size: 512
timeout: 10s
send_batch_max_size: 512
exporters:
otlp/traces-mtls-missing-values--missing-all:
endpoint: ${OTLP_ENDPOINT_TRACES_MTLS_MISSING_VALUES__MISSING_ALL}
tls:
insecure: true
insecure_skip_verify: true
sending_queue:
enabled: true
queue_size: 85
retry_on_failure:
enabled: true
initial_interval: 5s
max_interval: 30s
max_elapsed_time: 300s
otlp/traces-mtls-missing-values--missing-all-but-ca:
endpoint: ${OTLP_ENDPOINT_TRACES_MTLS_MISSING_VALUES__MISSING_ALL_BUT_CA}
tls:
insecure: true
ca_pem: ${env:OTLP_TLS_CA_PEM_TRACES_MTLS_MISSING_VALUES__MISSING_ALL_BUT_CA}
sending_queue:
enabled: true
queue_size: 85
retry_on_failure:
enabled: true
initial_interval: 5s
max_interval: 30s
max_elapsed_time: 300s
otlp/traces-mtls-missing-values--missing-ca:
endpoint: ${OTLP_ENDPOINT_TRACES_MTLS_MISSING_VALUES__MISSING_CA}
tls:
insecure: true
cert_pem: ${env:OTLP_TLS_CERT_PEM_TRACES_MTLS_MISSING_VALUES__MISSING_CA}
key_pem: ${env:OTLP_TLS_KEY_PEM_TRACES_MTLS_MISSING_VALUES__MISSING_CA}
sending_queue:
enabled: true
queue_size: 85
retry_on_failure:
enabled: true
initial_interval: 5s
max_interval: 30s
max_elapsed_time: 300s |
|
@k15r I want to try to reproduce this. Can you give an example of what is in your env var that's failing (not the real value, something fake) and the steps you took to create the env var. |
|
use this env-file (no worries, just some test ca cert and key data): and use the previous config. my response with 104 without feature gate disabled: (yepp, i changed the error message to include the certificate data) With the feature disabled it starts up normally. |
|
I was able to reproduce the problem, but not using your exact config. The problem occurs, as the issue description suggests, when expanding the env variable using the If I use I still need to investigate what the envprovider is doing wrong with the value. Test config: receivers:
nop:
exporters:
otlp:
endpoint: https://api.honeycomb.io:443
tls:
insecure: true
ca_pem: ${env:OTLP_TLS_CA_PEM_TRACES_MTLS_MISSING_VALUES__MISSING_ALL_BUT_CA}
service:
telemetry:
logs:
level: debug
pipelines:
traces:
receivers:
- nop
exporters:
- otlpenv var: |
|
#10603 is, pending testing, a possible solution. The root cause of this may be go-yaml/yaml/issues/963 or some related issue in our YAML parser, but maybe we shouldn't parse YAML strings at all |
|
@mx-psi Thank you for tackling this! |
RonFed
added a commit
to odigos-io/odigos
that referenced
this issue
Aug 8, 2024
Relevant breaking changes in the collector that are addressed in this PR (from the [contribe releases](https://github.com/open-telemetry/opentelemetry-collector-contrib/releases) and [collector release](https://github.com/open-telemetry/opentelemetry-collector/releases). > The otlpreceiver now uses localhost by default instead of 0.0.0.0. This may break the receiver in containerized environments like Kubernetes. If you depend on 0.0.0.0 disable the component.UseLocalHostAsDefaultHost feature gate or explicitly set the endpoint to 0.0.0.0 > confmap: When passing configuration for a string field using any provider, use the verbatim string representation as the value. (open-telemetry/opentelemetry-collector#10605, open-telemetry/opentelemetry-collector#10405) This matches the behavior of ${ENV} syntax prior to the promotion of the confmap.unifyEnvVarExpansion feature gate to beta. It changes the behavior of the ${env:ENV} syntax with escaped strings
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Describe the bug
When attempting to configure TLS using environment variables for the contents of the certs there is an error parsing the value of the certificates.
Steps to reproduce
Use the following configuration file:
Create a
ca.pemfile with the content:Set env variable to the content of the cert:
Run otel collector with the configuration file:
otelcol --config config.ymlWhat did you expect to see?
I expected that when
ca_pem: ${env:CA_PEM}was specified that otel collector would parse the cert.What did you see instead?
When
ca_pem: ${env:CA_PEM}is specified, I get the following error:When I comment out that configuration and use either
ca_pem: | CONTENTorca_file: ca.pemthe above error is not present and the collector starts up.What version did you use?
Version: 0.102.1
What config did you use?
The above configuration file.
Environment
Docker image:
golang:1.22otelcolwas fetched from Github and unpacked within the docker image manually.Additional context
The text was updated successfully, but these errors were encountered: