Remove dedicated front-proxy client CA

[xrstf]

Summary

When I originally designed the PKI for the kcp-operator, I thought having separate CAs for front-proxy and the shards made sense. However it turns out this is causing more havoc by making kubeconfigs just so useless: You can read an APIExportEndpointSlice through the front-proxy, but then cannot access any of the endpoints because the shards/virtual-workspaces use a different client CA.

Due to this, the kcp-operator already deploys a CA bundle for the client CA in the front-proxy, a bundle consisting of the root client CA and the front-proxy's client CA.

This PR goes one step further and simply removes the old front-proxy client CA entirely, but introducing a new clientCASecretRef field for FrontProxy objects, so admins can configure their
own client CA (or any other) here and have it still be included in the front-proxy. Since we have already always configured both client CAs, this is not losing any pre-existing flexibility, we're just reducing the minimum number of CAs that a front-proxy runs from 2 to 1.

---

I also refactored the reconcilerFunc a bit, making it stateless. I then also cleaned up the controller a bit and renamed the "merged CA" to "backendCABundle" (in the code only, no Kube object name changes), which IMHO describes its purpose much better. From the documentation saying "is used to validate API Server certs", I couldn't immediately tell which API Servers :D

The adminKubeconfigCertificateReconciler has been removed entirely, since its not mounted anywhere and never actually used, especially now that we only have one client CA.

What Type of PR Is This?

/kind cleanup
/kind api-change

Release Notes

TBD

[kcp-ci-bot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please assign embik for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Details

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[xrstf]

/test all

[ntnn]

but introducing a new clientCASecretRef field for FrontProxy objects,

Shouldn't that be on the root shard and the front proxy and shards include that as well if its set? Right now the front-proxy does authn/z and the shards trust that, but users that connect to a shard or virtual workspace directly still get declined if they have the custom ca signed client cert.

[xrstf]

My thought was that you might want to have different Client CA Bundles for each FrontProxy. So making every FP automatically inherit everything from the RootShard only would kind of break that.

However I can see how having a custom CA in the FP only, which is then not part of the shards or VWs, is right where we started.

Tbh I originally added the ClientCA bundle to the FrontProxy API only as a means to keep backwards-compatibility, in order to get this merged I then sold it as a feature 😁

How sold are you on this PR also introducing ClientCABundles to (Root)Shards/VWs?

[ntnn]

How sold are you on this PR also introducing ClientCABundles to (Root)Shards/VWs?

I think it'd be a good idea overall. We could drop the fp client CA, use the root client CA everywhere and downstream can add their custom ca using clientCABundles?
I wouldn't be opposed to fp/shards having clientCABundles as well as a property.

We already have a number of properties that could default to the root shard value but don't, or?
Then not default fp/shard to the root shard value would just be following what we do already.

[xrstf]

Okay, I've extended the API to include a ClientCABundle in the CommonShardSpec, and in VWs, and added inheritance, some tests and updated the docs. Granting access has never been easier!(tm).