Detects attempts to forge or approve Kubernetes CertificateSigningRequests (CSRs) in Azure Kubernetes Service (AKS) that request or mint client certificates signed by kubernetes.io/kube-apiserver-client. Adversaries use this to obtain long‑lived client certificates tied to arbitrary subjects (e.g., system:masters), enabling durable authentication that persists beyond token revocation. The rule monitors AKS diagnostic logs (azure.platformlogs) for CSR creation (signerName kubernetes.io/kube-apiserver-client) or approval (subresource approval) events, including the related base64 CSR payload to read the requested subject (Common Name and Groups). It also correlates the signer, verb (create, update/patch on approval), and response status, and excludes known legitimate CSRs from node bootstrap, kubelet, cert-manager, and platform controllers. Workload service accounts (system:serviceaccount:ns:sa) and other elevated identities are considered higher risk, as they may be used to mint a client certificate that bypasses token-based authentication. The detection logic accounts for in-cluster abuse where a compromised in-cluster token could be used to forge a certificate that grants privileged access (e.g., system:masters), with attention to issuer constraints (signerName) and the certificate subject. The rule maps to MITRE ATT&CK tactic Credential Access (T1649: Forge or Steal Authentication Certificates) and provides targeted triage steps, false-positive considerations, and remediation guidance, including revoking misissued certificates, reviewing related RBAC, and collecting kube-audit artifacts for IR workflows. It requires enabling Azure Fleet integration to ingest AKS diagnostic logs via Event Hub (azure.platformlogs) and distinguishes CSRs for the kube-apiserver-client signer from other signers (e.g., kube-apiserver-client-kubelet, kubelet-serving) which are out of scope. Overall, this detection focuses on anomalous CSR creation/approval activity that could enable persistent, privileged access within AKS clusters.