…verify

[v4.y] Test VERIFY_PEER / VERIFY_NONE work against real cluster

Test sandwitches the real CA cert between two unrelated CA certs
(another-ca1.pem, another-ca2.pem, simply copied from two runs of
update_certs_k0s.rb).
No test for root+intermediate scenario.

Fails before the backport of ManageIQ#461:

KubeclientConfigTest#test_concatenated_ca [/home/beni/kubeclient/test/test_config.rb:196]:
Expected false to be truthy.

(some experimenting with order suggests only first cert is honored.)
Passes with the fix.

…-add-file

Load cluster ca certificates using OpenSSL::X509::Store#add_file

(cherry picked from commit 53408c1)

- Helps confirm suspected OS-specific failures.
- Normally when one build fails, most other builds already started and
  some almost complete `bundle install` / started tests.
  So it's not a big "waste" expensive to let them finish, arguably it's
  actually a waste to abort them! (sunken cost fallacy? :-)
- In case rubocop complains, while I do consider it a merge blocker,
  it's better contributor (and maintainer) experience to also see test results.

…-file

[v4.y] Load cluster ca certificates using OpenSSL::X509::Store#add_file

- VULNERABILITY FIX: Previously, whenever kubeconfig did not define
  custom CA (normal situation for production clusters with public domain
  and certificate!), `Config` was returning hard-coded `VERIFY_NONE` :-(

  Assuming you passed those ssl_options to Kubeclient::Client,
  this means that instead of checking server's certificate against
  your system CA store, it would accept ANY certificate, allowing easy
  man-in-the middle attacks.

  This is especially dangerous with user/password or token credentials
  because MITM attacker could simply steal those credentials to the
  cluster and do anything you could do on the cluster.

- Bug fix: kubeconfig `insecure-skip-tls-verify` field was ignored.
  When kubeconfig did define custom CA, `Config` was returning hard-coded
  `VERIFY_PEER`.

  Now we honor it, return `VERIFY_NONE` iff kubeconfig has explicit
  `insecure-skip-tls-verify: true`, otherwise `VERIFY_PEER`.

These don't affect code that supplies `Client` parameters directly,
only code that uses `Config`.

(To ease back-porting, this commit is rebased directly on the 6-year-old
PR that introduced Kubeclient::Config - this was broken from day 1!
ManageIQ#127
Tests come in separate commits based on later points.)

…verify_ssl]

- Removed `insecure-skip-tls-verify: true` from most test configs
  (that was one of the reasons the bug went unnoticed, VERIFY_NONE
  was what the unit tests expected.)

- Added new kubeconfig files + `Config` unit tests covering:
  - custom CA, omitted `insecure-skip-tls-verify`
  - custom CA, `insecure-skip-tls-verify: false`
  - custom CA, `insecure-skip-tls-verify: true`
  - no custom CA, omitted `insecure-skip-tls-verify`
  - no custom CA, `insecure-skip-tls-verify: false`
  - no custom CA, `insecure-skip-tls-verify: true`

…uster

…rify

[v4.y] SECURITY: Kubeclient::Config: return ssl_options[:verify_ssl] correctly

Releasing 4.9.3

Tiny followup to ManageIQ#556.
Sorry for noise, had these locally but forgot to push before merging.
If I start backporting, CHANGELOG.md on master branch might not always be updated
with all backports (it SHOULD, but it will require separate merges to master).
So I prefer pointing to the vulnerability issue as the "source of truth".
Also, security impact will be better discussed on the issue.

…rify-changelog

fixup CHANGELOG and README about ManageIQ#554, ManageIQ#555

…erify