Bug 1805168 - openshift-controller-manager makes direct http requests even when a proxy is set
Summary: openshift-controller-manager makes direct http requests even when a proxy is set
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: openshift-controller-manager
Version: 4.3.0
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
: 4.5.0
Assignee: Gabe Montero
QA Contact: wewang
Whiteboard: devex
Depends On:
TreeView+ depends on / blocked
Reported: 2020-02-20 12:11 UTC by Christophe Fergeau
Modified: 2020-07-13 17:16 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Cause: the image stream signature controller in the openshift controller manager deployment makes direct http/https requests to registries accessed by imagestreams, and the openshift controller manager was not being set up to deal with global proxies Consequence: global proxies were not properly utilized by the image signature controller in the openshift controller manager Fix: the openshift controller manager operator now seeds the openshift controller manager with the proxy environment variables and ca certificates needed to properly communicate with openshift global proxy Result: the image signature controller now leverages openshift global proxies correctly when contacting external registries
Clone Of:
Last Closed: 2020-07-13 17:16:23 UTC
Target Upstream Version:

Attachments (Terms of Use)

System ID Priority Status Summary Last Updated
Github openshift cluster-openshift-controller-manager-operator pull 145 None closed Bug 1805168: inject global proxy envs,ca into OCM daemonset 2020-08-31 15:08:37 UTC
Red Hat Product Errata RHBA-2020:2409 None None None 2020-07-13 17:16:48 UTC

Description Christophe Fergeau 2020-02-20 12:11:31 UTC
I'm using a test cluster (4.3.0-0.nightly-2020-02-17-205936) on AWS with a proxy configured:

$ oc get proxy cluster -ojson
    "apiVersion": "config.openshift.io/v1",
    "kind": "Proxy",
    "metadata": {
        "creationTimestamp": "2020-02-19T11:12:28Z",
        "generation": 1,
        "name": "cluster",
        "resourceVersion": "427",
        "selfLink": "/apis/config.openshift.io/v1/proxies/cluster",
        "uid": "8f210775-bf6a-46fc-948b-b4934396de96"
    "spec": {
        "httpProxy": "http://proxy-user1:JYgU8qRZV4DY4PXJbxJK@ec2-3-16-66-156.us-east-2.compute.amazonaws.com:3128",                                                                                              
        "httpsProxy": "http://proxy-user1:JYgU8qRZV4DY4PXJbxJK@ec2-3-16-66-156.us-east-2.compute.amazonaws.com:3128",                                                                                             
        "noProxy": "test.no-proxy.com",
        "trustedCA": {
            "name": ""
    "status": {
        "httpProxy": "http://proxy-user1:JYgU8qRZV4DY4PXJbxJK@ec2-3-16-66-156.us-east-2.compute.amazonaws.com:3128",                                                                                              
        "httpsProxy": "http://proxy-user1:JYgU8qRZV4DY4PXJbxJK@ec2-3-16-66-156.us-east-2.compute.amazonaws.com:3128",                                                                                             
        "noProxy": ".cluster.local,.svc,.us-east-2.compute.internal,,,,,,api-int.sunilc-190243.qe.devcluster.openshift.com,etcd-0.sunilc-190243.qe.devcluster.openshift.com,etcd-1.sunilc-190243.qe.devcluster.openshift.com,etcd-2.sunilc-190243.qe.devcluster.openshift.com,localhost,test.no-proxy.com"                                                              

If I then run tcpconnect from bcc-tools on the node, I'm getting this kind of output:
26551  openshift-co 4    443 
ie some TCP connections are made directly to the https port on rather than going through the http proxy which is using port 3128

It seems some parts of this pod are not using the proxy even if it's set.

Comment 12 Christophe Fergeau 2020-04-24 07:31:54 UTC
For what it's worth, I tested this on 4.4, and I can still reproduce the issue. This is expected as the fix was not backported to 4.4 and is only available in 4.5+.

Comment 13 Gabe Montero 2020-04-24 12:03:19 UTC
Yep, at this time the fix has not been backported to any releases prior to 4.5.

Comment 15 errata-xmlrpc 2020-07-13 17:16:23 UTC
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.


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