client: Add feature flag for BoringSSL TLS

[hawkw]

Motivation

Curerently, kube-client supports using either Rustls or OpenSSL as the
TLS backend. BoringSSL is an alterative TLS implementation, based on a
fork of OpenSSL and maintained by Google. Rust bindings for BoringSSL
are available in the boring crate. Some users of kube-client may
wish to use BoringSSL as the TLS implementation, rather than OpenSSL or
Rustls. This can potentially be implemented in downstream code, on top
of kube-client's config module, but this would require re-implementing
a large amount of kube-client's auth module in user code. Therefore,
it seemed nicer to just provide it in kube-client.

Solution

This commit adds support for BoringSSL as a third TLS option. The
boring crate has a very similar API to the openssl crate, so the
BoringSSL client code looks quite similar to the OpenSSL client code.

I've also attempted to modify the CI configuration to also run tests
with BoringSSL. However, I wasn't able to verify that this works without
an actual CI run, so it's possible that the E2E test docker environment
can't actually build BoringSSL and we'll have to add additional build
deps there. I'm happy to follow up on that after a CI run has completed.

[codecov]

Codecov Report

Merging #1301 (c4fcfea) into main (83368df) will not change coverage.
The diff coverage is n/a.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #1301   +/-   ##
=======================================
  Coverage   72.31%   72.31%           
=======================================
  Files          75       75           
  Lines        6347     6347           
=======================================
  Hits         4590     4590           
  Misses       1757     1757           

Files	Coverage Δ
kube-client/src/client/builder.rs	71.42% <ø> (ø)
kube-client/src/client/config_ext.rs	48.07% <ø> (ø)
kube-client/src/client/mod.rs	71.91% <ø> (ø)
kube-client/src/client/tls.rs	63.63% <ø> (ø)

[hawkw]

The Clippy failures on CI look unrelated, but it looks like there's a linker failure with --all-features when both OpenSSL and BoringSSL are on the link path, which I didn't see when building locally. That's unfortunate; I'll have to dig into that.

[clux]

Hey, thanks for this! I think the reasoning makes sense for it to be here.

1. The extension of the ssl feature selection makes sense. It probably needs to be extended/duplicated into the oidc and the oauth client modules for consistency. There might be a smarter way to do that than to just duplicate it.

2. The e2e test for boring ssl is unfortunately stepping on a musl landmine. The cross compiled dep is missing. I am open to extending the env, maybe moving onto a different test env, or relegating boring e2e to some future PR.

3. Clippy issues will be fixed in Clippy --fix on runtime pedantics #1302. Cargo deny looks "legit", but probably can't really do anything about it except add an ignore directive about the duplicate versions dep atm.

[hawkw]

@clux thanks for the quick feedback!

• The extension of the ssl feature selection makes sense. It probably needs to be extended/duplicated into the oidc and the oauth client modules for consistency. There might be a smarter way to do that than to just duplicate it.

Ah, I didn't realize that we also selected a TLS implementation there. I'll make sure it's consistent.

• The e2e test for boring ssl is unfortunately stepping on a musl landmine. The cross compiled dep is missing. I am open to extending the env, maybe moving onto a different test env, or relegating boring e2e to some future PR.

Thanks for the link, that's helpful. However, after looking further, it seems like the linker issue isn't actually Musl-specific --- note that --all-features also fails on MacOS: https://github.com/kube-rs/kube/actions/runs/6383547275/job/17324381680?pr=1301#step:8:1080

It's possible that the boring-sys and openssl-sys dependencies just can't exist in the same binary, due to the OpenSSL and BoringSSL C libraries exporting the same symbol names? If so, that's really unfortunate: it kind of implies we can't actually use feature flagging to control which dependency is used, since we want an --all-features build to compile successfully...

[hawkw]

I wonder if sfackler/rust-openssl#1944 is related?

[hawkw]

Oh, actually, I bet the problem is fixed just by changing the oidc and oauth modules to also use BoringSSL. That way, the binary should never contain any functions that actually use OpenSSL symbols, and we shouldn't attempt to link with both C libraries. At least I hope so...

Edit: nope, never mind, I was wrong about that --- with --all-features, we use Rustls anyway, so both BoringSSL and OpenSSL are dead code. Hmm.