LoFP LoFP / selfsubjectaccessreview (\"can i do x\") is routinely issued by controllers checking their own permissions, so busy clusters generate benign volume from platform and add-on service accounts (for example kube-system managed add-ons such as azure-policy, microsoft defender, metrics-server, and konnectivity, plus operators like cert-manager, ingress controllers, and argo/flux). the rule ships with only the azure arc agent accounts (system:serviceaccount:azure-arc:*) excluded; that namespace exists only on arc-enabled clusters and is one example, not a complete list. treat the exclusion set as a per-environment denylist: baseline the calling service accounts and add validated platform/observability controllers after review. selfsubjectrulesreview (\"list everything i can do\") is far rarer from non-human identities and higher signal. admin impersonation workflows can also trigger this via an impersonated service account; validate the impersonating user.

Techniques

Sample rules

Azure AKS Suspicious Self-Subject Review by Service Account or Node Identity

Description

Detects AKS (Azure Kubernetes Service) service account or node identities invoking self-subject access or rules review APIs. Non-human identities rarely enumerate their own permissions outside known controllers; this can indicate stolen tokens probing effective RBAC before privilege escalation.

Detection logic

data_stream.dataset:azure.platformlogs and
  event.action:Microsoft.ContainerService/managedClusters/diagnosticLogs/Read and
  azure.platformlogs.category:(kube-audit or kube-audit-admin) and
  azure.platformlogs.properties.log.stage:ResponseComplete and
  azure.platformlogs.properties.log.verb:create and
  azure.platformlogs.properties.log.objectRef.resource:(selfsubjectaccessreviews or selfsubjectrulesreviews) and
  azure.platformlogs.properties.log.user.username:((system\:node\:* or system\:serviceaccount\:*) and
  not system\:serviceaccount\:azure-arc\:*)