Kubetier
← Permission Reference
T3

get certificatesigningrequests

Reading a CertificateSigningRequest returns its status, including the issued certificate once a signer has populated it.

This is the retrieval step of certificate minting.

Without a read verb, a successfully issued certificate stays out of reach.

T0 with following verbs:

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

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

Completes the chain: submit, approve, then collect the signed certificate.

Every step is a separate RBAC grant and all four are needed.

API Group
certificates.k8s.io
Scope
cluster
Audit Level
Metadata

Escalation Paths

  1. List the User subjects already bound to cluster-admin via kubectl get clusterrolebinding.

    The name is distribution specific: cluster-admin on kubeadm, clusterAdmin and clusterUser on AKS.

  2. Create a CSR using a CN matching one of those usernames and request the kubernetes.io/kube-apiserver-client signer.

  3. Approve the CSR.

    This requires both update on certificatesigningrequests/approval and approve on signers for that exact signerName.

  4. The built-in signing controller issues a real, CA-signed certificate automatically.

    No CA key or extra access is needed from the caller.

  5. The cert authenticates as the matched username, inheriting all its RBAC permissions.

    It works until expiry.

    Individual revocation requires CA rotation.

Additional rights 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.

K8s docs ↗
  1. The submission guard rejects only the literal group system:masters, so an O=system:nodes request is accepted

  2. Request a certificate with O=system:nodes and CN=system:node: followed by the name of a real node

  3. Approving it returns a CA-signed client certificate, issued in seconds and valid for years

  4. The Node authorizer then grants the Secrets, ConfigMaps and PVCs referenced by pods scheduled on that node

  5. Objects no pod on that node references are refused as having no relationship to it, and bulk list is refused, so the reach is that node workload set

  6. A TokenRequest bound to a pod on that node mints that pod ServiceAccount token, including one carrying a cloud identity audience

  7. There is no revocation for client certificates, so deleting the request leaves an issued certificate valid until it expires

  8. On a single node cluster every pod runs on that node, so the node workload set is the whole cluster and the practical reach approaches full compromise

Additional rights needed:

Note:

Not patched and not a defect: only system:masters is guarded at submission.

Remediation is preventive, since an issued certificate cannot be revoked and only rotating the CA invalidates it.

K8s docs ↗

See Also

K8s docs ↗