create certificatesigningrequests
A submitted CertificateSigningRequest issues nothing by itself.
It sits Pending until something approves and signs it, so its value is only as the entry point for a certificate the API server will trust, a path that takes three further grants.
T0 with following verbs:
Authenticate to the API server as any user, in any group
scoped to signerName kubernetes.io/kube-apiserver-client
Approving your own request for this signer makes the built-in controller issue the certificate, and the API server authenticates it by CN and O.
Signer policy rejects some values, including system:masters.
Note:
CSR-created client certificates cannot be individually revoked by Kubernetes once issued; revocation generally means rotating the underlying CA or waiting for expiry.
- API Group
- certificates.k8s.io
- Scope
- cluster
- Audit Level
- RequestResponse
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:
· 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.