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
DescriptionChristophe 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,10.0.0.0/16,10.128.0.0/14,127.0.0.1,169.254.169.254,172.30.0.0/16,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 10.128.0.33 184.84.75.132 443
ie some TCP connections are made directly to the https port on 184.84.75.132 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 12Christophe 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+.
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.
https://access.redhat.com/errata/RHBA-2020:2409
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,10.0.0.0/16,10.128.0.0/14,127.0.0.1,169.254.169.254,172.30.0.0/16,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 10.128.0.33 184.84.75.132 443 ie some TCP connections are made directly to the https port on 184.84.75.132 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.