mjudeikis
commented
1 year ago /approve /lgtm
Can you trow this picture into hacks dir Readme file? Would like to preserve this for future me :D
Closed xrstf closed 1 year ago
mjudeikis
commented
1 year ago /approve /lgtm
Can you trow this picture into hacks dir Readme file? Would like to preserve this for future me :D
kcp-ci-bot
commented
1 year ago LGTM label has been added. Git tree hash: 04d1cb25f8b7999e1d69d611ff7707bf6f25f619
mjudeikis
commented
1 year ago /lgtm /approve
kcp-ci-bot
commented
1 year ago LGTM label has been added. Git tree hash: ab84a312aae347b70b9e6229ffaf634ec49cbbd9
kcp-ci-bot
commented
1 year ago [APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: mjudeikis
The full list of commands accepted by this bot can be found here.
The pull request process is described here
This PR cleans up the PKI and fixes some bugs. I was trying to set up a local test environment and for that I replicated the PKI using
certin(or any other CLI to generate certs), but found that using my PKI, my virtual workspace could not communicate with the kcp shard. After some further digging (because this worked perfectly fine using the Helm chart), I found that the chart makes some weird decisions on how it uses the clean PKI it created. Meaning that the PKI structure makes total sense, but the CLI flags had some weirdness to them that I consider bugs.letsencrypt-cawas removed. Since #38 the certificate wasn't even the LE CA anymore, it wasCN = kcp.faros.sh Not After: May 22 13:33:10 2023 GMT. The supposed LE CA was used as the-root-ca-file, which to me doesn't make sense as LE won't be signing certificates inside kcp. This is what thekcp-service-account-signing-cais probably meant to be used for.kcp-selfsigned-issuerwas removed, as the default issuer for the kcp-front-proxy cert was changed to be thekcp-server-issuer. There is no good reason in my mind why the front-proxy should not simply use the existing kcp CA.kcp-pki-caissuer was renamed tokcp-pkito be more consistent with the other issuer names.external-logical-cluster-admin-kubeconfigused the wrong CA. The CA should be the one that issued the front-proxy's server, not the cert itself.logical-cluster-admin-kubeconfigused the wrong CA. The CA should be the one that issued kcp's server, not the CA of the client-auth.values.yaml, allowing users to integrate external virtual workspaces. To make PKI work for those,extraVolumesandextraVolumeMountscan be added to the kcp-front-proxy.kcp-front-proxy:--client-ca-file=/etc/kcp-front-proxy/client/tls/ca.crtis pointing to the CA that signed thekcp-client-ca, which is effectively the kcp PKI CA. I assume the intention was to actually specify thekcp-client-ca, so this was adjusted accordingly.values.yamlas needed.kcp:--client-ca-file=/etc/kcp-front-proxy/client/tls/ca.crtis the same issue as with the front-proxy.--requestheader-client-ca-file=/etc/kcp/tls/requestheader-client/ca.crtis the same issue as with--client-ca-file: this accidentally used the CA of the CA.--root-ca-file=/etc/kcp/tls/ca/root-ca.pempointed to the seemingly-LE-but-not-really CA, which should not be the CA for the cluster, as all relevant certificates are created internally. The value was therefore changed to/etc/kcp/tls/service-account/ca.crt, to dynamically use whatever CA signed thekcp-service-accountcertificate (usually this is done internally, but to be flexible and make fewer assumptions, we do not hardcode the CA).--shard-virtual-workspace-ca-file=/etc/kcp/tls/ca/root-ca.pemshould not actually be relevant, as core virtual workspaces run in-process, but nonetheless the kcp cert is not signed by LE and so this flag was adjusted to/etc/kcp/tls/kcp-virtual-workspaces/ca.crt(the CA for a future, not yet existing, external kcp-virtual-workspace server).With this PR applied, the intended structure of the PKI is like so:
(Apologies, this is a Google slide and not something easily maintainable.)