update certificatesigningrequests/approval

Approval alone does not write a certificate.

It only marks a pending CertificateSigningRequest approved, after which a signer may issue one.

It is rejected on its own without approve on signers for the request's exact signerName.

Combined with create on certificatesigningrequests for the kube-apiserver-client signer, it becomes privilege escalation.

T0 with following verbs:

Authenticate to the API server as any user, in any group

scoped to signerName kubernetes.io/kube-apiserver-client

A self-submitted request is approved and the built-in controller issues a trusted certificate, so the caller never needs a CA key.

Escalation Paths

Enumerate User subjects already bound to cluster-admin or other high-privilege ClusterRoles via kubectl get clusterrolebinding.
Create a CSR using a CN matching one of those usernames and request the kubernetes.io/kube-apiserver-client signer.
Approve the CSR.
This requires both update on certificatesigningrequests/approval and approve on signers for that exact signerName.
The built-in signing controller issues a real, CA-signed certificate automatically.
No CA key or extra access is needed from the caller.
The cert authenticates as the matched username, inheriting all its RBAC permissions.
It works until expiry.
Individual revocation requires CA rotation.

Additional rights needed:

T2create certificatesigningrequests+T2approve signers+T3get certificatesigningrequests
· scoped to signerName kubernetes.io/kube-apiserver-client
· all four; no CA key needed

Note:

The CSR API remains dangerous for kube-apiserver client certificates, but the direct built-in system:masters request is rejected by signer policy.

Custom signers or certificates for other bound high-privilege identities can still be escalation paths.