Bug 1574570 - Ability to validate input fields for certs and keys in Routes, declining to create a Route object if the input is not well defined
Summary: Ability to validate input fields for certs and keys in Routes, declining to c...
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: Networking
Version: 3.7.1
Hardware: All
OS: All
unspecified
medium
Target Milestone: ---
: 3.11.0
Assignee: Ben Bennett
QA Contact: zhaozhanqi
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-05-03 14:55 UTC by Gonzalo Marcote
Modified: 2022-08-04 22:20 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-06-06 17:34:42 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Gonzalo Marcote 2018-05-03 14:55:20 UTC
Description of problem:
OpenShift should perform input validation and check that key and cert fields are correct when creating one secured route-> https://docs.openshift.com/container-platform/3.7/dev_guide/routes.html#creating-routes
and reject route object creation if not valid.

Version-Release number of selected component (if applicable):
All OCP versions (3.7, 3.9) and HAproxy (1.5, 1.8)

How reproducible:
Always

Steps to Reproduce:
1. Create one route specifying one malformed key or cert () in secured route yaml definition:
 tls:
    termination: edge
    key: |-
      -----BEGIN PRIVATE KEY-----
      [...]
      -----END PRIVATE KEY-----
    certificate: |-
      -----BEGIN CERTIFICATE-----
      [...]
      -----END CERTIFICATE-----
2. It allows to create route object
3. It doesn't validate input fields for certs and keys despite they are not correct.

Actual results:
It allows to create route object

Expected results:
To validate input fields for certs and keys in Routes, declining to create a Route object if the input is bad (either an encrypted key or just junk text), rather than creating a badly specified route object, which a Router implementation must then check and decline to implement.

Additional info:

Comment 1 Ben Bennett 2018-05-03 15:19:55 UTC
@ramr: Is there a reason we can't make the apiserver validate the route objects?  It seems like a reasonable thing to do.  But we might want the apiserver to be more tolerant so that different router implementations can support different keys.

Comment 2 Ram Ranganathan 2018-05-03 19:03:17 UTC
@ben: afaicr, we had to do this via an ExtendedValidation controller in the template router. When that work was done, the first/initial version of it did do those checks in the API server (I too felt catching it early is better).
So ... at that point in time, there were a few concerns mostly around that we don't break backward compatibility. And as result it was done in a new extended validation controller in the template router. Also some of the validation errors are "point-in-time" related ala may happen post-creation time (ala certificate expiry and revocation lists).

Comment 3 Ben Bennett 2018-06-06 17:34:42 UTC
@ram: Ah, right.  That makes sense.  Thank you.


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