This rule detects the creation or approval of Kubernetes CertificateSigningRequests (CSRs) by non-system identities, a common post-compromise persistence technique. If an attacker with cluster access submits a CSR containing a privileged Common Name (CN) such as system:kube-controller-manager or system:masters and subsequently approves it, they can obtain a long‑lived client certificate that persists across pod restarts, token revocation, and RBAC changes. The detection targets Kubernetes audit logs (logs-kubernetes.audit_logs-*) and filters for CSR resources with verbs create, update, or patch, focusing on cases where the authorization decision is allowed while the requester is not part of trusted system principals. Excluded principals cover known high-privilege system accounts to reduce noise, though legitimate processes (e.g., cert-manager, bootstrap workflows) may require tune‑ups to avoid false positives. The rule recommends decoding the CSR payload from kubernetes.audit.requestObject.spec.request, inspecting the CSR subject CN (and known high‑risk identities such as system:masters, system:kube-controller-manager, system:admin), and correlating with subsequent authentication, RBAC changes, and TokenRequest activity. Triage steps include verifying whether the same actor created and approved the CSR within a short window, reviewing kubernetes.audit.objectRef, and analyzing the certificate’s usage. Remediation involves revoking or rotating the cluster CA if abused, denying approvals, deleting the CSR, and tightening signer restrictions to prevent untrusted issuers. This aligns with MITRE ATT&CK techniques T1098 (Account Manipulation) and T1098.006 (Additional Container Cluster Roles).