[Rule Tunings] Kubernetes/GKE Sensitive RBAC Change Followed by Workload Modification - #6699
Merged
Merged
Conversation
…oad Modification These two rules fire when the same identity writes a Role/ClusterRole and then modifies a Deployment/DaemonSet/CronJob within five minutes. Over 30d on latest versions, Kubernetes rule had 105367 hits / 5 licenses / 6 clusters; 103688 were `system:serviceaccount:flux-system:kustomize-controller` and 1228 were `helm-controller` (plus 343 alerts that omitted `kubernetes.audit.user.username` on the alert doc but still had the `kustomize-controller` user agent so those should drop as well) - accounted for 99.9% of alerts. The GKE rule had much less volume (324 / 2 license / 4 clusters), but to keep parity I'm tuning it as well. Alert docs do not show `client.user.email`, so after is estimated from `Esql.user_agent_original_values`: 208 `kustomize-controller` and 22 `flux-operator` (230, 71% alert reduction). The rule is meant to catch a person or stolen credential that first widens Role/ClusterRole permissions, then immediately creates or patches a Deployment/DaemonSet/CronJob as the payload. Flux’s kustomize-controller, helm-controller, and source-controller (and on GKE, flux-operator) are the in-cluster accounts Flux uses to apply whatever is in Git. If that Git path includes both a ClusterRole and a Deployment, the controller will write RBAC and then update the workload in the same sync. That is Flux applying declared config, not an attacker granting themselves cluster rights and shipping a malicious pod. I also updated tags
imays11
requested review from
Aegrah,
Samirbous,
bryans3c,
eric-forte-elastic,
shashank-elastic,
terrancedejesus and
w0rk3r
August 25, 2026 20:20
imays11
added
Domain: Cloud Workloads
Rule: Tuning
w0rk3r
approved these changes
Sep 1, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Pull Request
Issue link(s):
Summary - What I changed
These two rules fire when the same identity writes a Role/ClusterRole and then modifies a Deployment/DaemonSet/CronJob within five minutes. Over 30d on latest versions, Kubernetes rule had 105367 hits / 5 licenses / 6 clusters; 103688 were
system:serviceaccount:flux-system:kustomize-controllerand 1228 werehelm-controller(plus 343 alerts that omittedkubernetes.audit.user.usernameon the alert doc but still had thekustomize-controlleruser agent so those should drop as well) - accounted for 99.9% of alerts.The GKE rule had much less volume (324 / 2 license / 4 clusters), but to keep parity I'm tuning it as well. Alert docs do not show
client.user.email, so after is estimated fromEsql.user_agent_original_values: 208kustomize-controllerand 22flux-operator(230, 71% alert reduction).The rule is meant to catch a person or stolen credential that first widens Role/ClusterRole permissions, then immediately creates or patches a Deployment/DaemonSet/CronJob as the payload. Flux’s kustomize-controller, helm-controller, and source-controller (and on GKE, flux-operator) are the in-cluster accounts Flux uses to apply whatever is in Git. If that Git path includes both a ClusterRole and a Deployment, the controller will write RBAC and then update the workload in the same sync. That is Flux applying declared config, not an attacker granting themselves cluster rights and shipping a malicious pod.
I also updated tags