Bug 1565069 - Should add related validation for Ingress host
Summary: Should add related validation for Ingress host
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: Routing
Version: 3.10.0
Hardware: All
OS: All
medium
medium
Target Milestone: ---
: 3.11.0
Assignee: Miciah Dashiel Butler Masters
QA Contact: zhaozhanqi
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-04-09 10:09 UTC by zhaozhanqi
Modified: 2018-08-01 15:05 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-08-01 15:05:12 UTC
Target Upstream Version:


Attachments (Terms of Use)

Description zhaozhanqi 2018-04-09 10:09:47 UTC
Description of problem:
for now, ingress did not do validation, for example. 
1. The 'host' can be exceed 63 characters
2. we can create 2 same host 

when doing 'oc get ing', it's showing:
$ oc get ing
NAME            HOSTS                                                                           ADDRESS   PORTS     AGE
test            1.qwertyuioplkjhgfdsazxcvbnmlkjhgfdsaqwertyuiopmnbvcxzasqwertingress-test.com             80        23m
test-ingress    foo.bar.com                                                                               80        16m
test1-ingress   foo.bar.com 


but it's mapping routes will be marked as 

$ oc get route
NAME                  HOST/PORT            PATH      SERVICES           PORT      TERMINATION   WILDCARD
test-ingress-8dzft    foo.bar.com                    service-unsecure   8080                    None
test-smjwp            InvalidHost          /test     service-unsecure   8080                    None
test1-ingress-tqw2m   HostAlreadyClaimed             service-unsecure   8080                    None

so should add related validation in ingress side also. otherwise, if the ingress can be shown correctly for user, but in fact it cannot be used.

Version-Release number of selected component (if applicable):
v3.10.0-0.16.0

How reproducible:
always


Steps to Reproduce:
1. Create ingress with 'host' exceed 63 characters
2. Create two ingresses with same 'host'
3. check the ingress
   oc get ing

Actual results:

As $Description

Expected results:

step 3 the 'host' should show same as `oc get route`


Additional info:

Comment 1 Dan Mace 2018-06-08 14:07:02 UTC
Quick update here: the IngressRule host length validation issue needs to be verified and an issue filed upstream to fix validation at the API level. The host field is specified as a DNS-1123 subdomain.

Regarding the duplicate Ingress hosts: k8s Ingress doesn't have a claim mechanism[1], so technically the two Ingress resources are valid in k8s  by design; how an ingress controller (e.g. the OpenShift router) should react to this state is unspecified. In practice, it looks like the OpenShift router does something reasonable (grants a claim to the oldest Ingress). So in that regard, I think the only issue with the OpenShift router is a documentation gap: we should describe our ingress controller's behavior in this case when acting as a k8s ingress controller.

[1] https://github.com/kubernetes/kubernetes/issues/30151

Comment 2 Dan Mace 2018-06-15 15:15:33 UTC
Upon further review, RFC[1] states:

    Host software MUST handle host names of up to 63 characters and SHOULD handle host names of up to 255 characters.

Kube seems to conform in this regard[2].

[1] https://tools.ietf.org/html/rfc1123#section-2.1
[2] https://github.com/kubernetes/apimachinery/blob/master/pkg/util/validation/validation.go#L128

Comment 3 Dan Mace 2018-06-15 18:22:21 UTC
Upon further further review,

The Ingress resource validation seems to be correct in terms of its stated type (an RFC1123 hostname), but the question remains as to whether it should be something like a DNS FQDN (whereby each subdomain segment would be validated as a DNS label). The OpenShift Route is ultimately rejecting the name as an invalid FQDN, but the unaccepted Route status isn't reflected back into the Ingress status.

It's not clear that the "valid" Ingress would actually be usable in terms of DNS. We should engage upstream about the field to clarify the meaning of the IngressRule.Host field.

In the meantime, given the impedance mismatch between Route and Ingress in this regard, perhaps confusion could be minimized by reflecting the invalid Route status back to the Ingress status so it's at least clear that the Ingress is not being fulfilled.

Comment 4 Dan Mace 2018-08-01 15:05:12 UTC
Given the severity of this report we don't believe we'll be able to prioritize this issue in the short or medium term. We apologize that we are going to close the bug as WONTFIX.


Note You need to log in before you can comment on or make changes to this bug.