More Info:
Approving CertificateSigningRequests can issue client certificates that impersonate any identity. Limit access to the approval sub-resource.Risk Level
MediumAddress
SecurityCompliance Standards
- CIS Kubernetes
Triage and Remediation
- Remediation
Remediation
Manual Steps
Manual Steps
-
List all ClusterRoles with CSR approval access
- Run on: any machine with kubectl access
Save the resulting ClusterRole names; these are the ones to review. -
Inspect each identified ClusterRole’s rules and intended use
- For each ClusterRole name from step 1, run:
- Review:
- Who/what this role is meant for (name/annotations/labels, any documented use).
- Exact rules granting access to
certificatesigningrequests/approval(verbs likeapprove,update,patchvia that sub-resource).
-
Determine whether approval access is strictly required
For each ClusterRole:- Identify all RoleBindings/ClusterRoleBindings using it:
- For each bound subject (user, group, service account), confirm with application/operations owners whether they actually need to approve CSRs, or only to request/view them.
- Identify all RoleBindings/ClusterRoleBindings using it:
-
Reduce or remove CSR approval rights where not required
For each ClusterRole where approval is not strictly needed:- Edit and remove the
certificatesigningrequests/approvalresource from its rules (or remove the rule entirely if only for approval): - In the editor, under
rules:, delete any entry that includes: - If no other permissions in the ClusterRole are required, consider removing the bindings or deleting the ClusterRole:
- Edit and remove the
-
Restrict necessary approval access to the minimum set of subjects
Where approval access is truly needed:- Ensure the ClusterRole scope is minimal (only CSR approval and closely related, necessary verbs).
- Tighten bindings to the smallest possible set of users/groups/service accounts, and use names/labels that clearly indicate high-privilege usage.
- Update bindings as needed:
-
Re-verify that unnecessary approval access is removed
- Re-run the discovery to confirm only intentional roles remain:
- Cross-check each remaining ClusterRole and its bindings as in steps 2–3 to ensure that all holders of CSR approval rights are explicitly justified.
- Re-run the discovery to confirm only intentional roles remain:
Using kubectl
Using kubectl
Any ClusterRole name in this list has permission to approve CSRs. Each must be reviewed to confirm that this access is truly required.
rules: section:apiGroupscontainscertificates.k8s.ioresourcescontainscertificatesigningrequests/approvalverbsincludes powerful actions such asupdateor*
- The ClusterRole is generic/broad (e.g. used by many users or groups).
- The ClusterRole is bound to wide subjects such as
system:authenticated,system:masters, or broad groups.
Bindings that attach these ClusterRoles to:
- Very broad groups (e.g.
system:authenticated,system:unauthenticated, or large SSO groups). - ServiceAccounts or users that do not have an explicit operational need to approve CSRs.
Automation
Automation
kubectl and jq configured for the cluster.Output indicating a problem:- Any ClusterRole or Role name shown in the first two sections.
- Any ClusterRoleBinding or RoleBinding listed, especially where subjects are broad (e.g.
system:authenticated,system:masters, or wide service-account patterns).

