|Summary:||Moving the API port from 6443 is currently not possible|
|Product:||OpenShift Container Platform||Reporter:||Erik M Jacobs <ejacobs>|
|Component:||Master||Assignee:||Michal Fojtik <mfojtik>|
|Status:||CLOSED WONTFIX||QA Contact:||Xingxing Xia <xxia>|
|Version:||4.1.0||CC:||aos-bugs, chernand, crawford, decarr, esauer, jmatthew, jokerman, mmccomas, nmalik, wgordon|
|Fixed In Version:||Doc Type:||If docs needed, set a value|
|Doc Text:||Story Points:||---|
|Last Closed:||2019-04-11 22:21:11 UTC||Type:||Bug|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Cloudforms Team:||---||Target Upstream Version:|
Description Erik M Jacobs 2019-03-06 19:51:05 UTC
Description of problem: OCP3.x supported changing the API port. Certain environments and situations (customer policy, etc) mean that any tool that doesn't talk across a standard port (80/443) may be blocked. In that case, anything that needs to access the API on 6443 would be blocked. This would break the CLI, IDE, and any RESTful API integrations. The web console is available over 443, and one could get access to a CLI running "inside" the OCP environment, however that still leaves IDE and API integrations broken.
Comment 6 Alex Crawford 2019-04-08 23:08:55 UTC
This looks like a duplicate of 1663453. Is there any new information that needs to be considered or can this be closed?
Comment 7 Erik M Jacobs 2019-04-09 13:10:15 UTC
This is not a dupe of 1663453 1663453 says "put the API port on 8443". This BZ is "make the API port configurable".
Comment 8 Alex Crawford 2019-04-11 00:41:57 UTC
Okay, maybe not a dup, but it shares the same conclusion: > We've decided to stick with 6443 for the API. We'll make a point to educate customers about the port change. Unless there is a compelling reason to do so, we should not allow the API port to be customized.
Comment 9 Erik M Jacobs 2019-04-11 14:57:49 UTC
Not allowing for the customization of the API port means that there are some potential users who will not be able to access the API for whatever reason. If we don't allow for moving the API port, then we likely need to document and support some type of proxy solution in front of the API.
Comment 10 Alex Crawford 2019-04-11 22:21:11 UTC
I'm not convinced. These potential users would have to be smart enough to block access to 6443 but not smart enough to provide a proxy. That seems very unlikely and since we don't have any concrete examples, I'm going to close this. We can revisit this if it proves to be problematic in the future.
Comment 11 Eric Sauer 2019-08-20 15:06:28 UTC
Can we understand why putting the api on a non-standard SSL port is necessary or useful in the first place? In OpenShift 3.x, we used 8443 for the API because it was possible/supported to run the router on the control plane, and we needed to avoid port conflicts on the host. But in OpenShift 4, we require dedicated control plane hosts and taint the those servers so nothing else gets scheduled there. There are no port conlficts to protect against. Why wouldn't we run the api on 443 by default?
Comment 12 Alex Crawford 2019-08-29 18:49:37 UTC
There is a growing use case for edge clusters, which don't have any worker nodes. In these environments, the port conflict does exist.
Comment 13 Will Gordon 2019-12-03 18:40:00 UTC
Adding my perspective from a hosted perspective (OpenShift Dedicated/OpenShift Online). Most of these customer's are much less technical, which is why they're investing in a hosted solution. Typically there are corporate policies put in place at a higher level, that the hosted customers (typically just developers) don't have any chance of being to change or workaround with a proxy. Because this limitation exists in the installer, we have *no way* of supporting these customers. We already have 1 concrete example of a customer being blocked by this, and OSD on v4 is still fairly small. This will absolutely be a hinderance to the expansion and adoption of our hosted offerings.