WIP: Proof of concept for using Kube CSR API in TokenCredentialRequest #1070
Conversation
|
Closing this out since the POC was sufficient for the CSR Duration KEP GA requirements. |
|
Related issue for EKS supporting CSRs for client auth: aws/containers-roadmap#1604 |
|
Related side note: As of a couple years ago, AKS clusters did not allow anonymous auth. https://kubernetes.slack.com/archives/C5HJXTT9Q/p1591587619012300 Is this still true? If so, it could prevent users from being able to access the Concierge's TokenCredentialRequest endpoint to be able to log in, which would have an impact on the approach outlined in this PR for AKS users. It also will not work for EKS users for the reason mentioned in my previous comment. It might work on GKE as a replacement for the impersonation proxy strategy, and it would work on Kind/TKG/similar clusters as a replacement for the "kube cert agent" strategy. |
This is a proof of concept of using the Kube CSR API in the TokenCredentialRequest endpoint to create client certs. It is related to #715.
Today, the Pinniped Concierge uses either the Kube API server's CA's private key to create a cert, or it uses its own CA for the impersonation proxy. Using the Kube CSR API would be an alternative approach which is only possible in Kube 1.22+ thanks to kubernetes/kubernetes#99494.
This proof of concept was written to explore the potential impact on the Pinniped code of using the CSR API for this purpose, including getting a sense of the performance penalty compared to how Pinniped works today.
This PR does not attempt to include unit tests or pass linter checks. It is not expected to pass CI. It does pass all integration tests when run on a development laptop using Kind 0.12.0 with Kubernetes 1.23.
Before this change, the part of the TCR handler which creates the client cert usually takes 2-3ms on Kind on my laptop. Sometimes a call takes more like ~100ms (and rarely up to ~250ms). I'm assuming that this has something to do with the mutex locking inside the issuer code which ensures that the controller can update the issuer cache atomically, but I did not try to confirm this suspicion. For the purpose of this exploration it seems good enough to say that it is usually 2-3ms on my laptop.
With this proof of concept, the runtime of the endpoint has become highly variable compared to before. In 116 runs, the endpoint's cert creation runtime varied from 17ms to 691ms. The average was 75.4ms, and the median was 36ms. The standard deviation was 96.6ms, indicating that the runtimes were highly variable.
Release note:
This PR is not intended to be merged.