Fix validation of ESXi network configuration

[ahadas]

Currently, all validations fail because we cannot access the hosts with secure connections. In #656 the code has changed to take the configuration of the client connection from the secret, however, the secret of the ESXi hosts is never set with the insecure flag.

This change practically makes the client to the hosts be always insecure. It's not that significant because the data we get from the host does not include data that could be confidential.

[sonarqubecloud]

Quality Gate passed

Kudos, no new issues were introduced!

0 New issues
0 Security Hotspots
No data about Coverage
0.2% Duplication on New Code

See analysis details on SonarCloud

[ahadas]

@liranr23 let's have the discussion you started offline here please

i think overall defaulting to insecure isn't such a good idea

right but I don't think we have much choice since we don't set a certificate for interacting with the hosts (even a certificate for vCenter is not easy to set - currently we rely on users to check the skip certificate check or set the certificate on their own)

what does it mean "we can't access the hosts"?

in order to check the credentials we try to login to the host, but we cannot do any action with the host when we don't allow skipping the certificate validation, unless we set a valid certificate

[liranr23]

@liranr23 let's have the discussion you started offline here please

i think overall defaulting to insecure isn't such a good idea

right but I don't think we have much choice since we don't set a certificate for interacting with the hosts (even a certificate for vCenter is not easy to set - currently we rely on users to check the skip certificate check or set the certificate on their own)

what does it mean "we can't access the hosts"?

in order to check the credentials we try to login to the host, but we cannot do any action with the host when we don't allow skipping the certificate validation, unless we set a valid certificate

ok.. so it's up to the user to set it right and get secured connection by any means or skip it. what's wrong with that?

[ahadas]

@liranr23 let's have the discussion you started offline here please

i think overall defaulting to insecure isn't such a good idea

right but I don't think we have much choice since we don't set a certificate for interacting with the hosts (even a certificate for vCenter is not easy to set - currently we rely on users to check the skip certificate check or set the certificate on their own)

what does it mean "we can't access the hosts"?

in order to check the credentials we try to login to the host, but we cannot do any action with the host when we don't allow skipping the certificate validation, unless we set a valid certificate

ok.. so it's up to the user to set it right and get secured connection by any means or skip it. what's wrong with that?

that was about vCenter..

ok, I see my previous comment was confusing, let's focus on this issue - there are two cases:

1. the provider is set with an insecure connection (which is the scenario that is tested by us and virt-v2v guys): previously, it worked well and now the validation of the ESXi configuration fails because the code tries to get that configuration about the connection from the secret for the host and doesn't find anything so we initiate a client with insecure == false. this is an important regression we need to fix quickly.
2. the provider is set with secure connection (a scenario that is not tested, we were unable to set it properly - there's a good chance that it doesn't work since 2.4, which is something we intend to address in 2.6): again, this configuration is not set on the secret for the host but due to the default value that is set when the configuration doesn't exist, the client is created with secure connection. it also doesn't work because we don't set a certificate that can be used for interacting with the host. this is a known limitation but it's not that severe because secure connections to vSphere is broken compared to MTV 2.3 and below

so we need to quickly address the first item
I'm not saying that there's no sense in trying to connect to vsphere using secured connections, but that's an item for 2.6 and I'm not quite sure it would actually work for the interaction with the hosts