Detects creation or update (including patch) of Kubernetes CertificateSigningRequests (CSRs) in AWS EKS control-plane audit logs when performed by a non‑system identity and the CSR is approved (authorization_k8s_io/decision:"allow"). A CSR with a privileged Common Name (CN) such as system:kube-controller-manager or system:masters can be used to mint a long‑lived client certificate that persists across pod relaunches, RBAC changes, or token revocation, enabling durable access to the cluster. The rule excludes common legitimate CSR workflows (e.g., cert-manager, bootstrap, or node bootstrap processes) by filtering out identities like system:kube-controller-manager, system:kube-scheduler, system:node:*, system:serviceaccount:kube-system:*, or eks:*. It maps to persistence and privilege escalation ATT&CK techniques (Account Manipulation T1098 with subtechnique Additional Container Cluster Roles T1098.006). The query targets the aws.eks_audit data stream, focusing on the certificatesigningrequests resource and verbs create/update/patch with an allow decision, and it’s designed to flag risky self‑approval patterns that warrant follow‑up. The rule includes triage guidance for extracting the CSR CN from the base64 request object, identifying high‑risk CNs, and correlating with RBAC changes, TokenRequest activity, and subsequent secret or credential access. Guidance for response covers denying the CSR, revoking/rotating signers, and tightening signer restrictions and approved issuers. Setup notes emphasize enabling EKS control‑plane audit logs, routing through the AWS integration, and validating data_stream.dataset: aws.eks_audit and cloud.provider: aws. This rule is a high‑severity detection aimed at identifying durable backdoors in Kubernetes environments, particularly on non‑EKS clusters where a signed certificate could grant broad, long‑lived access.