[New Rules] GCP GKE Rule Conversions Part 3

[imays11]

Pull Request

Issue link(s):

• https://github.com/elastic/ia-trade-team/issues/979

Summary

Converts five Kubernetes Fleet privilege-abuse rules to GKE/GCP Fleet audit format (logs-gcp.audit-*, service.name:"k8s.io"). Validated on trade-lab and Zocalo cluster.

---

GKE Ephemeral Container Added to Pod
Original: https://github.com/elastic/detection-rules/blob/main/rules/integrations/kubernetes/privilege_escalation_kubernetes_ephemeral_container_added_to_pod.toml

Detects update/patch of pods/ephemeralcontainers — a common post-compromise debug-shell technique.

---

GKE Exposed Service Created With Type NodePort Original: https://github.com/elastic/detection-rules/blob/main/rules/integrations/kubernetes/persistence_kubernetes_exposed_service_created_with_type_nodeport.toml

Detects create/update/patch of a Service with spec.type: NodePort.

Key changes: Excludes system:addon-manager on services.patch only. (based on telemetry)

---

GKE Service Account Token Created via TokenRequest API Original: https://github.com/elastic/detection-rules/blob/main/rules/integrations/kubernetes/credential_access_kubernetes_service_account_token_created.toml

Detects serviceaccounts/token create (kubectl create token / TokenRequest API).

---

GKE API Server Proxying Request to Kubelet
Original: https://github.com/elastic/detection-rules/blob/main/rules/integrations/kubernetes/privilege_escalation_kubernetes_proxy_to_node.toml

Detects API-server proxy to the node kubelet (nodes/proxy).

---

GKE API Request Impersonating Privileged Identity Original: https://github.com/elastic/detection-rules/blob/main/rules/integrations/kubernetes/privilege_escalation_kubernetes_api_request_impersonating_privileged_identity.toml

Detects successful API calls impersonating privileged identities (system:admin, controller-manager, kube-system SAs, nodes, etc.).

Key changes: GKE maps impersonation to gcp.audit.authentication_info.authority_selector (not impersonatedUser). No verb filter. --as-group (e.g. system:masters) is not exposed as a structured field in Cloud Audit Logs.

How To Test

Queries tested against Zocalo cluster, where no data found I emulated behavior to test in trade stack.

[github-actions]

Rule: New - Guidelines

These guidelines serve as a reminder set of considerations when proposing a new rule.

Documentation and Context

• Detailed description of the rule.
• List any new fields required in ECS/data sources.
• Link related issues or PRs.
• Include references.

Rule Metadata Checks

• creation_date matches the date of creation PR initially merged.
• min_stack_version should support the widest stack versions.
• name and description should be descriptive and not include typos.
• query should be inclusive, not overly exclusive, considering performance for diverse environments. Non ecs fields should be added to non-ecs-schema.json if not available in an integration.
• min_stack_comments and min_stack_version should be included if the rule is only compatible starting from a specific stack version.
• index pattern should be neither too specific nor too vague, ensuring it accurately matches the relevant data stream (e.g., use logs-endpoint.process-* for process data).
• integration should align with the index. If the integration is newly introduced, ensure the manifest, schemas, and new_rule.yaml template are updated.
• setup should include the necessary steps to configure the integration.
• note should include any additional information (e.g. Triage and analysis investigation guides, timeline templates).
• tags should be relevant to the threat and align/added to the EXPECTED_RULE_TAGS in the definitions.py file.
• threat, techniques, and subtechniques should map to ATT&CK always if possible.

New BBR Rules

• building_block_type should be included if the rule is a building block and the rule should be located in the rules_building_block folder.
• bypass_bbr_timing should be included if adding custom lookback timing to the rule.

Testing and Validation

• Provide evidence of testing and detecting the expected threat.
• Check for existence of coverage to prevent duplication.