I am working on introducing a new service, which will be deployed in an existing node alongside with other services.
The service needs to communicate with the Kubernetes API Server over HTTPS, so I have to perform TLS bootstrapping. I was able to generate a CSR, but I don't know how to configure controller manager to auto-approve the generated CSR.
I went through a lot of resources online, and found out that almost all of them are focusing on kubelet TLS bootstrapping, which doesn't apply to me as I am introducing a new service (not a new node that requires bootstrapping the kubelet). Correct me if I am wrong.
After contemplating my design for a while, I think that the service, after generating the CSR, can self-approve the CSR as well before sending it to the API Server. This means that the controller manager now only needs to sign the CSR: high-level flow chart
Is this the appropriate design from the security perspective? The controller manager still signs the CSR based on a Certificate Authority (CA), and the same CA is configured for both the controller manager and API Server.
An entire article on Certificate Signing Requests is available in official documentation. It's a good place to get you started.
What you want to achieve is possible by creating Custom controller, Normal user service account, and kubernetes.io/kube-apiserver-client signer.
You would need to create a controller that periodically queries API-Server for CSRs, and approve them.
Howerer, such controller would not be able to see what's inside the CSR, and therefore open your cluster to malicious CSR injection.
A Word of Warning on the Approval Permission:
The ability to approve CSRs decides who trusts whom within your environment. The ability to approve CSRs should not be granted broadly or lightly. The requirements of the challenge noted in the previous section and the repercussions of issuing a specific certificate should be fully understood before granting this permission.
