Verified in 4.3.0-0.nightly-2019-12-08-215349 From the ec2 console, create a network interface, then attach it to a worker. Before attaching the network interface, node has internal ip 10.0.134.214. After attaching the network interface, node has internal ips 10.0.134.214, 10.0.128.107 Meanwhile monitor the machine-approver-controller under openshift-cluster-machine-approver namespace. Could see that when the new interface is attached, a CSR is generated pending approval. The first several attempts for approval was not successful because the machine did not have '10.0.128.107' in machine address ``` I1209 06:29:07.577927 1 main.go:146] CSR csr-p6m9p added I1209 06:29:07.725777 1 csr_check.go:417] retrieving serving cert from ip-10-0-134-214.us-east-2.compute.internal (10.0.134.214:10250) I1209 06:29:07.730781 1 csr_check.go:162] Found existing serving cert for ip-10-0-134-214.us-east-2.compute.internal W1209 06:29:07.730934 1 csr_check.go:171] Could not use current serving cert for renewal: CSR Subject Alternate Name values do not match current certificate W1209 06:29:07.730964 1 csr_check.go:172] Current SAN Values: [ip-10-0-134-214.us-east-2.compute.internal 10.0.134.214], CSR SAN Values: [ip-10-0-134-214.us-east-2.compute.internal 10.0.128.107 10.0.134.214] I1209 06:29:07.731022 1 csr_check.go:182] Falling back to machine-api authorization for ip-10-0-134-214.us-east-2.compute.internal I1209 06:29:07.731039 1 main.go:181] CSR csr-p6m9p not authorized: IP address '10.0.128.107' not in machine addresses: 10.0.134.214 I1209 06:29:07.731052 1 main.go:217] Error syncing csr csr-p6m9p: IP address '10.0.128.107' not in machine addresses: 10.0.134.214 ``` Later machine was updated with 2 internal IPs. status: addresses: - address: 10.0.134.214 type: InternalIP - address: 10.0.128.107 type: InternalIP - address: ip-10-0-134-214.us-east-2.compute.internal type: InternalDNS - address: ip-10-0-134-214.us-east-2.compute.internal type: Hostname lastUpdated: "2019-12-09T06:32:32Z" Then the machine-approver successfully approved it. ``` I1209 06:34:35.745522 1 main.go:146] CSR csr-p6m9p added I1209 06:34:35.761089 1 csr_check.go:417] retrieving serving cert from ip-10-0-134-214.us-east-2.compute.internal (10.0.134.214:10250) I1209 06:34:35.765644 1 csr_check.go:162] Found existing serving cert for ip-10-0-134-214.us-east-2.compute.internal W1209 06:34:35.765795 1 csr_check.go:171] Could not use current serving cert for renewal: CSR Subject Alternate Name values do not match current certificate W1209 06:34:35.765822 1 csr_check.go:172] Current SAN Values: [ip-10-0-134-214.us-east-2.compute.internal 10.0.134.214], CSR SAN Values: [ip-10-0-134-214.us-east-2.compute.internal 10.0.128.107 10.0.134.214] I1209 06:34:35.765837 1 csr_check.go:182] Falling back to machine-api authorization for ip-10-0-134-214.us-east-2.compute.internal I1209 06:34:35.770321 1 main.go:196] CSR csr-p6m9p approved ```
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:0062