Description of problem:
If a user supplies additionalTrustedCAs in the install-config, but does not supply any other proxy configuration (proxy hostname, no_proxy domains), the installer copies the supplied CAs into a user-ca-bundle CM in the openshift-config namespace, but it does not link that CM into the proxy config resource via the "proxy.spec.trustedCA" field.
I would expect that it should. We had a user report that they performed the above steps in which they had no additional proxy configuration because they have a transparent proxy in their network (but it's a MITM proxy with its own cert, hence the need for additional CAs).
Ultimately they had to manually edit the proxy config after install to link to the user-ca-bundle to get things working. This should have happened automatically during install.
proxy config does not link to the additional CA bundle if no other proxy configuration content is provided at install time.
proxy config should always link to the additional CA bundle if one was supplied at install time.
> If a user supplies additionalTrustedCAs in the install-config, but does not supply any other proxy configuration (proxy hostname, no_proxy domains), the installer copies the supplied CAs into a user-ca-bundle CM in the openshift-config namespace, but it does not link that CM into the proxy config resource via the "proxy.spec.trustedCA" field.
that is expected behavior. By setting no proxy, the user is saying "nobody needs to care about proxy"
> We had a user report that they performed the above steps in which they had no additional proxy configuration because they have a transparent proxy in their network (but it's a MITM proxy with its own cert, hence the need for additional CAs).
that's more to the effect that all components should trust additional CAs because of various reasons one of them is MiTM transparent proxy. And I don't think we should be setting proxies.config.openshift.io trust here.
This is an RFE and not a bug.
Mirroring a comment from the PR that's been opened, I don't think we should do this, to be discussed during Thursday's group-g arch call.
https://github.com/openshift/enhancements/pull/115 aims to describe the path forward, deferring this to 4.4
At this point https://github.com/openshift/enhancements/pull/115 is not going to move forward for the reasons described in:
I think the only thing left to do on this bug is to ensure that the installer/api documentation of the install config's "AdditionalTrustedCAs" field is very clear about when those CAs will and will not be passed into the proxy config for the cluster.
If AdditionalTrustedCAs is just for proxies after all, don't we actually want the code change from ? With improved docs around the property too to make the scoping more clear. Also commented to this effect in . Not sure if it's best to hash this out here or there.
> If AdditionalTrustedCAs is just for proxies after all
i'm not aware that that's the case (but i also do not know what else it is used for, when no proxy config is supplied to the installer).
I think we made a mistake not defining an explicit "proxyCAs" field on the installerconfig, and instead using AdditionalTrustedCAs for seemingly two purposes (again not sure specifically what the second purpose is, but i'm pretty sure there is one, which is why https://github.com/openshift/installer/pull/2658 got pushback: there are cases where customers supply additional CAs but don't want them distributed to all components as the proxyCA)
perhaps it's for things like talking to a self-hosted disconnected mirror registry?
Talked this over a bit more with Ben, and I've spun out:
* installer#3039 to document the node and proxy additionalTrustBundle consumers.
* api#582 (via bug 1797107) to document the proxy trustedCA flow more explicitly.
Maybe still to do is explicitly testing just setting noProxy to get the proxy CA injection for the transparent-network-proxy case .
ah. Just setting noProxy will break the CVO, which only included proxy trust when httpsProxy is set . We can fix *that* narrowly by pulling trust from the trusted-ca-bundle ConfigMap (avoiding trustedCA, as recommended by the API docs ). I'll see if there's an existing CVO bug or file a new one...
Not a CVO bug, but some related discussion on MCO handling in  (and the rest of the bug, but I tried to summarize my current understanding in that comment).
I've filed bug 1797123 with an associated PR to move the CVO over to using trusted-ca-bundle.
Moving back to MODIFIED so the Errata sweeper will pick this up on the nightly build that includes installer#3039 (although as a change to the installer docs, verification won't actually depend on a nightly release image).
The doc changes in https://github.com/openshift/installer/pull/3039/files LGTM
*** Bug 1807103 has been marked as a duplicate of this bug. ***
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.