Bug 1802606
| Summary: | Cluster-wide proxy does not accept uppercase hostname | ||
|---|---|---|---|
| Product: | OpenShift Container Platform | Reporter: | Gabriel Stein <gferrazs> |
| Component: | Networking | Assignee: | Juan Luis de Sousa-Valadas <jdesousa> |
| Networking sub component: | openshift-sdn | QA Contact: | huirwang |
| Status: | CLOSED ERRATA | Docs Contact: | |
| Severity: | medium | ||
| Priority: | unspecified | CC: | huirwang, jdesousa, jnordell |
| Version: | 4.3.0 | ||
| Target Milestone: | --- | ||
| Target Release: | 4.4.0 | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: |
Cause:
Using httpProxy or httpsProxy hostname with uppercases makes the the CNO fatal, which is a violation of RFC3986.
Consequence:
CNO won't work at all and as it's cluster-critical it has a major impact.
Fix:
Parse it with golangs url.ParseRequestURI, which implements RFC3986 correctly and a few more RFCs.
Result:
Capital case is now allowed in httpProxy and httpsProxy
|
Story Points: | --- |
| Clone Of: | Environment: | ||
| Last Closed: | 2020-05-04 11:36:24 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
Gabriel Stein
2020-02-13 14:27:14 UTC
As per RFC3986 this should be allowed: https://tools.ietf.org/html/rfc3986#section-3.2.2 ~~~ The host subcomponent of authority is identified by an IP literal encapsulated within square brackets, an IPv4 address in dotted- decimal form, or a registered name. The host subcomponent is case- insensitive. ~~~ I see we use a dns 1123 matcher As per RFChttps://tools.ietf.org/html/rfc1123#page-13 ~~~ 2.1 Host Names and Numbers The syntax of a legal Internet host name was specified in RFC-952 [DNS:4]. One aspect of host name syntax is hereby changed: the restriction on the first character is relaxed to allow either a letter or a digit. Host software MUST support this more liberal syntax. Host software MUST handle host names of up to 63 characters and SHOULD handle host names of up to 255 characters. Whenever a user inputs the identity of an Internet host, it SHOULD be possible to enter either (1) a host domain name or (2) an IP address in dotted-decimal ("#.#.#.#") form. The host SHOULD check the string syntactically for a dotted-decimal number before looking it up in the Domain Name System. ~~~ And RFC 952 says: https://tools.ietf.org/html/rfc952 ~~~ 1. A "name" (Net, Host, Gateway, or Domain name) is a text string up to 24 characters drawn from the alphabet (A-Z), digits (0-9), minus sign (-), and period (.). Note that periods are only allowed when they serve to delimit components of "domain style names". (See RFC-921, "Domain Name System Implementation Schedule", for background). No blank or space characters are permitted as part of a name. No distinction is made between upper and lower case. ~~~ Now checking why this line is here, turns out what kubernetes calss DNS-1123 isn't actually RFC 1123: https://github.com/kubernetes/kubernetes/pull/39675 I believe this is a valid bug. Hi Gabriel,
Could you let me know the steps how to reproduce the issue?
I tried to reproduce the issue in old version by below way. But I cannot reproduce it.
With "oc edit proxy.config.openshift.io", using httpProxy or httpsProxy hostname with uppercases, no error messages.
huiran-mac:script hrwang$ oc edit proxy.config.openshift.io
proxy.config.openshift.io/cluster edited
huiran-mac:script hrwang$ oc get proxy.config.openshift.io -o yaml
apiVersion: v1
items:
- apiVersion: config.openshift.io/v1
kind: Proxy
metadata:
creationTimestamp: "2020-02-17T01:37:21Z"
generation: 3
name: cluster
resourceVersion: "719453"
selfLink: /apis/config.openshift.io/v1/proxies/cluster
uid: c000f406-f1b3-482b-b8a9-79c8200466ec
spec:
httpProxy: http://MYPROXY.EXAMPLE.COM:8080
httpsProxy: http://MYPROXY.EXAMPLE.COM:8080
trustedCA:
name: ""
status: {}
kind: List
metadata:
resourceVersion: ""
selfLink: ""
Verified in 4.4.0-0.nightly-2020-02-18-200822 Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2020:0581 |