LoFP LoFP / t1613

t1613

TitleTags
a workload or observability agent with partial rbac can be denied across several resource types and resemble enumeration (for example a monitoring agent that watches resources it lacks permission for). baseline such identities and raise the cardinality threshold, or exclude the specific validated service account, after review. single-resource retry loops (one resource denied repeatedly) do not trigger this rule because detection is based on the number of distinct resources denied, not the raw failure count.
administrators or developers may execute kubeletctl during legitimate troubleshooting or incident response to validate kubelet api connectivity or enumerate pods. confirm the user/session and change window before escalating.
administrators troubleshooting rbac from a workstation or vpn may generate mixed allow/deny results across many apis in a short window; tune by identity or source ip after validation.
an administrator may submit this request as an \"impersonateduser\" to determine what privileges a particular service account has been granted. however, an adversary may utilize the same technique as a means to determine the privileges of another token other than that of the compromised account.
authorized administrative maintenance via kubectl
automated internal infrastructure monitoring and certificate rotation
cluster operators and node diagnostics may legitimately probe kubelet endpoints (for example /pods or /metrics) during troubleshooting. validate the initiating user, session, and whether the target node/ip is expected for the host.
custom container tooling, ci agents, or monitoring may connect to docker.sock or containerd.sock from non-standard paths after relocation or bind mounts. tune by process.executable or user.name when noise is high.
engineers listing secrets from home isp or corporate vpn as names may match until baselined. geoip organization labels vary by vendor; tune exclusions after validation.
gitops controllers and cluster scanners can still match if not covered by built-in exclusions; baseline approved service accounts after review.
legitimate kubelet debugging, node troubleshooting, or security tooling that uses the node proxy outside the excluded metrics paths may match. baseline approved operators and automation identities after review.
legitimate node health checks, diagnostics, or in-cluster agents may access the kubelet api on port 10250. validate the calling process, command line, and whether the destination is the local node or another node.
new internal tools, sdks, or ci runners introduce novel user agents. baseline expected clients, then exclude stable automation uas after review.
newly deployed workloads with incomplete rolebindings can probe several apis during startup and encounter intermittent denials; exclude known service accounts if documented.
platform operators, installers, or runbooks that reconcile rbac and workload state may span these resource types in a short window; tune by identity, source ip, or user agent when documented.
security-approved vulnerability or secret scanning in devsecops pipelines
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.
some controllers and admin impersonation workflows legitimately submit self-subject reviews. excluded identities include common argo and datadog service accounts.
there is a potential for false positives if direct kubernetes api requests are used for legitimate purposes, such as debugging or troubleshooting. it is important to investigate any alerts generated by this rule to determine if they are indicative of malicious activity or part of legitimate container activity.
there is a potential for false positives if the \"env\" or \"printenv\" commands are used for legitimate purposes, such as debugging or troubleshooting. it is important to investigate any alerts generated by this rule to determine if they are indicative of malicious activity or part of legitimate container activity.
there is a potential for false positives if the \"id\", \"whoami\", \"capsh\", \"getcap\", or \"lsns\" commands are used for legitimate purposes, such as debugging or troubleshooting. for example, an operator may use the \"id\" command to verify the identity of the current user, or the \"whoami\" command to verify the current user. it is important to investigate any alerts generated by this rule to determine if they are indicative of malicious activity or part of legitimate container activity.
there is a potential for false positives if the \"jq\" command is used for legitimate purposes, such as debugging or troubleshooting. it is important to investigate any alerts generated by this rule to determine if they are indicative of malicious activity or part of legitimate container activity.
there is a potential for false positives if the \"which\" command is used for legitimate purposes, such as debugging or troubleshooting. it is important to investigate any alerts generated by this rule to determine if they are indicative of malicious activity or part of legitimate container activity.
there is a potential for false positives if the access to the service account token or certificate is used for legitimate purposes, such as debugging or troubleshooting. it is important to investigate any alerts generated by this rule to determine if they are indicative of malicious activity or part of legitimate container activity.
there is a potential for false positives if the container is used for legitimate administrative tasks that require the use of container management utilities, such as deploying, scaling, or updating containerized applications. it is important to investigate any alerts generated by this rule to determine if they are indicative of malicious activity or part of legitimate container activity.
there is a potential for false positives if the direct interactive kubernetes api requests are used for legitimate purposes, such as debugging or troubleshooting. it is important to investigate any alerts generated by this rule to determine if they are indicative of malicious activity or part of legitimate container activity.
there is a potential for false positives if the dns enumeration tools are used for legitimate purposes, such as debugging or troubleshooting. it is important to investigate any alerts generated by this rule to determine if they are indicative of malicious activity or part of legitimate container activity.
there is a potential for false positives if the reading of the service account namespace file is used for legitimate purposes, such as debugging or troubleshooting. it is important to investigate any alerts generated by this rule to determine if they are indicative of malicious activity or part of legitimate container activity.
there is a potential for false positives when the command line arguments looked for in this rule are used for legitimate purposes, such as debugging or troubleshooting. it is important to investigate any alerts generated by this rule to determine if they are indicative of malicious activity or part of legitimate container activity.
there is a risk of false positives if there are several containers named the same, as the rule may correlate the request to the wrong container.
unauthorized requests from service accounts are normal and expected behavior. analyze the user agent, pod and other node information to determine if the request is legitimate.