LoFP LoFP / gcp

gcp rule

TitleTags
administrators may enable hostipc for legitimate debugging. exclude trusted users or namespaces after baselining.
administrators routinely exec into pods for troubleshooting. baseline expected users and target pods, then exclude known break-glass identities.
anonymous api access is a dangerous default. health probes are excluded; investigate all other authorized anonymous requests and disable anonymous authentication where possible.
anonymous pod writes should be rare. if observed from expected automation, anonymous authentication or rbac for system:anonymous is likely misconfigured and should be remediated rather than broadly excluded.
application being removed may be performed by a system administrator.
approved certificate workflows (for example cert-manager, internal pki rotation, or node bootstrap) may create or update csrs from identities not in the exclusion list if they run under a custom service account. baseline automation that legitimately approves csrs and tune exclusions for those principals.
approved runbooks or support sessions may use kubectl exec with curl/wget to test egress or download vendor tools.
approved scripts, ci jobs, or penetration tests may use generic http clients. validate tickets and identity scope before treating as compromise.
automation that both submits and approves csrs in one workflow may trigger this rule. baseline cert-manager or internal pki pipelines and tune exclusions for known service accounts.
break-glass admin tooling, security scanners, or approved controllers that legitimately use impersonation against privileged targets may match. map expected callers and expand client.user.email exclusions as needed.
break-glass debugging from platform engineers may include curl to the metadata ip or hostname.
break-glass debugging or vendor diagnostics may cat credential-adjacent paths. baseline approved operators and automation identities, then expand client.user.email exclusions as needed.
built-in controller service accounts are rarely assigned to running pods. false positives should be rare; allowlist documented platform automation by actor when baselined.
cluster administrators may legitimately update coredns configuration for forwarding, stub domains, or cluster dns troubleshooting. baseline approved operators and automation identities; tune exclusions for known change pipelines.
cluster operators or sres may legitimately use ephemeral containers for debugging production workloads. baseline approved admin identities and tune exclusions for known automation.
custom pki or administrative tooling may legitimately request kubernetes.io/kube-apiserver-client certificates in self-managed clusters. baseline approved operators and tune exclusions for known automation on gke.
custom role creations may be done by a system or network administrator. verify whether the user email, resource name, and/or hostname should be making changes in your environment. role creations by unfamiliar users or hosts should be investigated. if known behavior is causing false positives, it can be exempted from the rule.
debug or break-glass pods may enable privilege escalation intentionally. exclude trusted namespaces, users, or deployment patterns after baselining.
debug pods may legitimately use hostpid. exclude trusted admin workflows after baselining.
developers may legitimately use nodeport for frontends without cloud load balancers, or for nonstandard networking. system:addon-manager patch reconciliation of existing nodeport services is excluded; create and update from addon-manager still alert.
developers or ci jobs with incomplete rbac can generate denied creates. tune after validating expected identities and namespaces. gke control-plane and bootstrap identities are excluded.
emergency kubectl changes, vpn or workstation migrations, and ci runner rotation can produce new user agent, source ip, and username combinations for authorized operators. baseline expected automation before tuning.
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.
exceptions can be added to this rule to filter expected behavior.
firewall rules being modified or deleted may be performed by a system administrator. verify that the firewall configuration change was expected.
firewall rules may be created by system administrators. verify that the firewall configuration change was expected. exceptions can be added to this rule to filter expected behavior.
firewall rules may be deleted by system administrators. verify that the firewall configuration change was expected. exceptions can be added to this rule to filter expected behavior.
firewall rules may be modified by system administrators. verify that the firewall configuration change was expected. exceptions can be added to this rule to filter expected behavior.
gitops and platform controllers (cert-manager, gatekeeper, kyverno, service mesh) legitimately manage webhooks. validate change tickets and controller identities before tuning.
gitops, namespace onboarding, and workload deployment commonly create rolebindings for service accounts. default bootstrap bindings from `system:apiserver` and gke node bootstrap from `gcp:kube-bootstrap` are excluded.
google cloud kubernetes admission controller may be done by a system administrator.
google cloud kubernetes cronjob/job may be done by a system administrator.
google workspace admin role privileges, may be modified by system administrators.
if known behavior is causing false positives, it can be exempted from the rule.
in-cluster controllers, operators, and ci jobs may legitimately reconcile rbac manifests. baseline known automation service accounts before tuning.
legitimate administrative activities
legitimate administrative activities changing the access levels for an application
legitimate forwarding
legitimate gke automation does not request certificates for system:masters, system:kube-controller-manager, or system:admin as the csr subject. node bootstrap and kubelet rotation use system:node:* identities instead. alerts should be rare; tune exclusions only for documented custom pki workflows that intentionally mint these identities.
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 logins
logging bucket deletions may be done by a system or network administrator. verify whether the user email, resource name, and/or hostname should be making changes in your environment. logging bucket deletions by unfamiliar users or hosts should be investigated. if known behavior is causing false positives, it can be exempted from the rule.
logging sink deletions may be done by a system or network administrator. verify whether the user email, resource name, and/or hostname should be making changes in your environment. logging sink deletions by unfamiliar users or hosts should be investigated. if known behavior is causing false positives, it can be exempted from the rule.
logging sink modifications may be done by a system or network administrator. verify whether the user email, resource name, and/or hostname should be making changes in your environment. sink modifications from unfamiliar users or hosts should be investigated. if known behavior is causing false positives, it can be exempted from the rule.
mfa may be disabled and performed by a system administrator.
monitoring agents and cni components may require hostnetwork. exclude known platform identities after review.
new internal tools, sdks, or ci runners introduce novel user agents. baseline expected clients, then exclude stable automation uas after review.
new or unusual event and user geolocation activity can be due to manual troubleshooting or reconfiguration; changes in cloud automation scripts or workflows; adoption of new services; expansion into new regions; increased adoption of work from home policies; or users who travel frequently.
new or unusual user event activity can be due to manual troubleshooting or reconfiguration; changes in cloud automation scripts or workflows; adoption of new services; or changes in the way services are used.
node agents and observability daemonsets commonly mount host paths like /proc or /var/log. controller ownerreferences exclusions reduce noise; add image exceptions if needed.
platform agents, admission webhooks, and ci jobs may legitimately call tokenrequest under non-standard identities. baseline approved automation by client.user.email after validation. expected gke and kube-system controllers are excluded; expand exclusions if additional managed components appear in telemetry.
platform installers, gitops controllers, and emergency break-glass roles sometimes ship or widen wildcard clusterroles; correlate with change records and narrow by user or service account when baselined.
platform installers, gitops controllers, and rbac refactoring may legitimately create roles with broad permissions. baseline approved automation and tune exclusions for known operators.
rare and unusual failures may indicate an impending service failure state. rare and unusual user failure activity can also be due to manual troubleshooting or reconfiguration attempts by insufficiently privileged users, bugs in cloud automation scripts or workflows, or changes to iam privileges.
role deletions may be done by a system or network administrator. verify whether the user email, resource name, and/or hostname should be making changes in your environment. role deletions by unfamiliar users or hosts should be investigated. if known behavior is causing false positives, it can be exempted from the rule.
rolebindings and clusterrolebinding being modified or deleted may be performed by a system administrator. verify whether the user identity, user agent, and/or hostname should be making changes in your environment.
rolebindings and clusterrolebinding modified or deleted from unfamiliar users should be investigated. if known behavior is causing false positives, it can be exempted from the rule.
secrets modified or deleted from unfamiliar users should be investigated. if known behavior is causing false positives, it can be exempted from the rule.
security training, ctf-style images, or vendor diagnostics may include bash redirection or /dev/tcp examples. baseline approved images then expand exclusions as needed.
service account being disabled or deleted may be performed by a system administrator. verify whether the user identity, user agent, and/or hostname should be making changes in your environment.
service account being modified may be performed by a system administrator. verify whether the user identity, user agent, and/or hostname should be making changes in your environment.
service account disabled or deleted from unfamiliar users should be investigated. if known behavior is causing false positives, it can be exempted from the rule.
service account key deletions may be done by a system or network administrator. verify whether the user email, resource name, and/or hostname should be making changes in your environment. key deletions by unfamiliar users or hosts should be investigated. if known behavior is causing false positives, it can be exempted from the rule.
service account keys may be created by system administrators. verify that the configuration change was expected. exceptions can be added to this rule to filter expected behavior.
service account modified from unfamiliar users should be investigated. if known behavior is causing false positives, it can be exempted from the rule.
service accounts can be created by system administrators. verify that the behavior was expected. exceptions can be added to this rule to filter expected behavior.
service accounts may be deleted by system administrators. verify that the behavior was expected. exceptions can be added to this rule to filter expected behavior.
service accounts may be disabled by system administrators. verify that the behavior was expected. exceptions can be added to this rule to filter expected behavior.
some controllers and admin impersonation workflows legitimately submit self-subject reviews. excluded identities include common argo and datadog service accounts.
some platform or security images legitimately require elevated capabilities. add image or namespace exceptions after review.
spikes in failures can also be due to bugs in cloud automation scripts or workflows; changes to cloud automation scripts or workflows; adoption of new services; changes in the way services are used; or changes to iam privileges.
sql database being modified or deleted may be performed by a system administrator.
sql database modified or deleted from unfamiliar users should be investigated. if known behavior is causing false positives, it can be exempted from the rule.
startup, helm, or controllers may legitimately touch many secrets in one window; tune by client.user.email, namespace, or ip allowlists when baselined.
storage bucket configuration may be modified by system administrators. verify that the configuration change was expected. exceptions can be added to this rule to filter expected behavior.
storage bucket permissions may be modified by system administrators. verify that the configuration change was expected. exceptions can be added to this rule to filter expected behavior.
storage buckets being enumerated may be performed by a system administrator. verify whether the user identity, user agent, and/or hostname should be making changes in your environment.
storage buckets being modified or deleted may be performed by a system administrator. verify whether the user identity, user agent, and/or hostname should be making changes in your environment.
storage buckets enumerated from unfamiliar users should be investigated. if known behavior is causing false positives, it can be exempted from the rule.
storage buckets may be deleted by a system or network administrator. verify whether the user email, resource name, and/or hostname should be making changes in your environment. bucket deletions by unfamiliar users or hosts should be investigated. if known behavior is causing false positives, it can be exempted from the rule.
storage buckets modified or deleted from unfamiliar users should be investigated. if known behavior is causing false positives, it can be exempted from the rule.
subscription creations may be done by a system or network administrator. verify whether the user email, resource name, and/or hostname should be making changes in your environment. subscription creations by unfamiliar users or hosts should be investigated. if known behavior is causing false positives, it can be exempted from the rule.
subscription deletions may be done by a system or network administrator. verify whether the user email, resource name, and/or hostname should be making changes in your environment. subscription deletions by unfamiliar users or hosts should be investigated. if known behavior is causing false positives, it can be exempted from the rule.
topic creations may be done by a system or network administrator. verify whether the user email, resource name, and/or hostname should be making changes in your environment. topic creations by unfamiliar users or hosts should be investigated. if known behavior is causing false positives, it can be exempted from the rule.
topic deletions may be done by a system or network administrator. verify whether the user email, resource name, and/or hostname should be making changes in your environment. topic deletions by unfamiliar users or hosts should be investigated. if known behavior is causing false positives, it can be exempted from the rule.
unknown
virtual private cloud networks may be deleted by system administrators. verify that the configuration change was expected. exceptions can be added to this rule to filter expected behavior.
virtual private cloud routes may be created by system administrators. verify that the configuration change was expected. exceptions can be added to this rule to filter expected behavior.
virtual private cloud routes may be deleted by system administrators. verify that the configuration change was expected. exceptions can be added to this rule to filter expected behavior.
vpn tunnel being modified or deleted may be performed by a system administrator.
vpn tunnel modified or deleted from unfamiliar users should be investigated. if known behavior is causing false positives, it can be exempted from the rule.