Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1825923

Summary: Fluentd pod doesn't honor noproxy definition when using CIDR format and accessing using an IP address
Product: OpenShift Container Platform Reporter: Oscar Casal Sanchez <ocasalsa>
Component: LoggingAssignee: Periklis Tsirakidis <periklis>
Status: CLOSED NOTABUG QA Contact: Anping Li <anli>
Severity: medium Docs Contact:
Priority: medium    
Version: 4.3.zCC: aos-bugs, jcantril, mburke, periklis
Target Milestone: ---Keywords: Reopened
Target Release: 4.5.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2020-05-04 14:22:25 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Oscar Casal Sanchez 2020-04-20 13:45:08 UTC
[Description of problem]

When a wide-cluster proxy is defined using in noproxy a CIDR format, the fluentd pod tryes to use the proxy always and doesn't honor the noproxy definition if you try to access by the IP address in the CIDR range.

This doesn't happen when a host is specified in the noproxy definition.

Use always the proxy when defined in CIDR format:

noProxy: 10.74.176.0/20,...

Don't use the proxy when defined like:

noProxy: 10.74.178.10,...

[Version-Release number of selected component (if applicable)]

Tested in OCP 4.3.10 and 4.3.12


[How reproducible]
Always


[Steps to Reproduce]

1. Define a wide-cluster proxy like this

~~~
apiVersion: config.openshift.io/v1
kind: Proxy
metadata:
...
spec:
  httpProxy: http://squid.corp.redhat.com:8080
  noProxy: .cluster.local,.svc,10.0.0.0/16,10.128.0.0/14,127.0.0.1,172.30.0.0/16,api-int.example.com,etcd-0.example.com,localhost,10.74.176.0/20
...
~~~

2. Delete fluentd pods for taking care of the new proxy definition
3. Check proxy env definition

~~~
http_proxy=http://proxy.example.com:8080
no_proxy=.cluster.local,.svc,10.0.0.0/16,10.128.0.0/14,10.74.176.0/20,127.0.0.1,172.30.0.0/16,api-int.example.com,etcd-0.example.com,localhost
HTTP_PROXY=http://proxy.example.com:8080
NO_PROXY=.cluster.local,.svc,10.0.0.0/16,10.128.0.0/14,10.74.176.0/20,127.0.0.1,172.30.0.0/16,api-int.example.com,etcd-0.example.com,localhost
~~~

4. Curl to an IP in the CIDR "14,10.74.176.0/20" and check how it's trying to use the proxy

~~~
$ oc rsh <fluentd pod>
sh-4.2# curl -vvv http://10.74.176.10:9300 -vvv
* About to connect() to proxy proxy.example.com port 8080 (#0)
*   Trying 10.11.5.35...
* Connected to proxy.example.com (10.11.5.35) port 8080 (#0)
> GET http://10.74.176.10:9300/ HTTP/1.1
> User-Agent: curl/7.29.0
> Host: 10.74.176.10:9300
> Accept: */*
> Proxy-Connection: Keep-Alive
> 

~~~ 

[Actual results]

Fluentd pod is not honoring the noproxy definition and it uses the proxy


[Expected results]

Fluentd pod honors the noproxy definition and not use the proxy for the defined noproxy entries.

[Additional information]

A similar BZ1768762 [1] was created where it's mentioned by Ben Parees in #C12 [2] the next: "2) Need to confirm the fluentd transport libraries support CIDR format noproxy values.  If they do not, we are going to need to find another way to ensure the requests from fluentd to elastic are not proxied." 

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1768762
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1768762#c12

Comment 1 Jeff Cantrill 2020-04-20 19:43:39 UTC

*** This bug has been marked as a duplicate of bug 1777477 ***

Comment 2 Oscar Casal Sanchez 2020-04-22 08:30:17 UTC
Hello,

Do you need some extra data for evaluating this issue from my side?

Comment 4 Periklis Tsirakidis 2020-04-24 13:20:03 UTC
@Oscar Casal Sanchez 

TL;DR; To our call, I cannot reproduce the issue by setting a proxy e.g. HTTP_PROXY=http://squid.corp.redhat.com:8080 and excluding the CIDR for my target Elasticsearch on my cluster. I believe it's only an issue of the outdated version of curl (7.29 released 2013) on our pods and a combination of NO_PROXY and no_proxy.

Comment 5 Oscar Casal Sanchez 2020-04-24 13:35:07 UTC
Hello,

Thank you so much for your feedback and so much appreciate your help and time dedicated. I'll verify again if the issue is really affecting to fluentd and it's not a problem with the curl version that it's not taking care of the noproxy definition correctly. Let me some time to check and verify it. 

Regards,
Oscar

Comment 10 Periklis Tsirakidis 2020-05-04 14:11:18 UTC
@Oscar

TL;DR; Using an IP address for the elasticsearch endpoint will not work with an IP-based no_proxy setting with ruby. The elasticsearch endpoint needs to be defined as a hostname that ruby can lookup. See:

https://github.com/ruby/ruby/blob/ruby_2_5/lib/uri/generic.rb#L1551
https://github.com/ruby/ruby/blob/ruby_2_5/lib/uri/generic.rb#L1541
https://github.com/ruby/ruby/blob/ruby_2_5/lib/uri/generic.rb#L1551

Comment 11 Periklis Tsirakidis 2020-05-04 14:22:25 UTC
Closing this issue based on https://bugzilla.redhat.com/show_bug.cgi?id=1825923#c10 it's not a bug.

Comment 12 Oscar Casal Sanchez 2020-05-05 07:59:14 UTC
Hello Periklis,

Thank you so much for your time dedicated and bring our attention to the issue related to using the IP Address in the endpoint. 

In the documentation is indicated the next in one of the examples:

"Add one or more endpoints:
   - ...
   - Enter the endpoint, either the server name or FQDN."

It's indicating that it should be a server name of FQDN, but I believe that it should be more clear in a Warning indicating that it shouldn't be used an IP Address. Then, I'll open a different Bugzilla to highlight this point.
 

Thank you,
Oscar