Skip to main content

More Info:

Approving CertificateSigningRequests can issue client certificates that impersonate any identity. Limit access to the approval sub-resource.

Risk Level

Medium

Address

Security

Compliance Standards

  • CIS Kubernetes

Triage and Remediation

Remediation

Manual Steps

  1. 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.
  2. 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 like approve, update, patch via that sub-resource).
  3. 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.
  4. Reduce or remove CSR approval rights where not required
    For each ClusterRole where approval is not strictly needed:
    • Edit and remove the certificatesigningrequests/approval resource 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:
  5. 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:
  6. 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.
Problem indication:
Any ClusterRole name in this list has permission to approve CSRs. Each must be reviewed to confirm that this access is truly required.

What to look for (problem indications):In the rules: section:
  • apiGroups contains certificates.k8s.io
  • resources contains certificatesigningrequests/approval
  • verbs includes powerful actions such as update or *
Example of a risky rule:
Flag as a concern when:
  • 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.

Problem indication:
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.
These bindings represent where the high‑risk approval capability is actually granted and should be manually reviewed and potentially tightened or removed.
Run this on any machine with 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).