Two RBAC grants let a subject create credentials rather than just use them. Create plus approval rights on certificate signing requests can mint client certificates, and create on serviceaccounts/token can issue tokens for existing service accounts. Both deserve a place on your access review.
Certificate signing requests
The RBAC good practices page explains the CSR path. Users with create rights on CertificateSigningRequests and update rights on certificatesigningrequests/approval, where the signer is the kube-apiserver client signer, can create new client certificates that let users authenticate to the cluster.
The docs add the dangerous part: those certificates can carry arbitrary names, including duplicates of Kubernetes system components. That effectively allows privilege escalation.
Link this to our post on system:masters. A certificate with the wrong group is a credential no binding can revoke.
TokenRequest
Users with create rights on serviceaccounts/token can create TokenRequests to issue tokens for existing service accounts. The risk follows the target: a token for a powerful account carries that account's rights. The grant is therefore only as safe as the most powerful service account it can reach.
Why people grant these
Platform tools need them. A certificate manager may need to approve requests. A CI system may request tokens to deploy. That is legitimate, but the grant should be tied to one identity and reviewed.
A realistic example
A team gives its deployment pipeline a role so it can request tokens for the deploy service account. Months later someone adds a second, more powerful account to the same namespace for a migration. The pipeline can now request tokens for it too, unless the rule names the original account. Nothing in the role changed. What it can reach did. Reviews should therefore look at the targets, not only the rule text.
How to find them
Search roles for these resources and for wildcards that cover them:
kubectl get clusterroles,roles -A -o yaml | grep -n -E "certificatesigningrequests|serviceaccounts/token"
Then, for each hit, record:
- Which subject holds it through a binding.
- Which signer or service accounts it can affect.
- Whether the subject needs it all the time or only during setup.
Narrowing
- Where RBAC allows it, limit rules with resourceNames so the grant covers named objects only.
- Remove approval rights from humans and keep them with automation you can audit.
- Remove token creation from workload service accounts unless they truly mint tokens.
- Use the audit log to alert on approvals and token requests outside change windows. Our audit policy post covers what to log.
Where Safeguard fits
Safeguard does not manage cluster credentials. It can hold review evidence through compliance and evidence automation, and apply policies and gates to the RBAC manifests in your repositories so an added grant is visible in review.
Quick check
Can a CSR approver pick any certificate name?
The docs say the certificates can have arbitrary names, including duplicates of system components, which is why the grant is an escalation path.
Sources
Last reviewed: 19 October 2026.
