56 results available
Sign in
Skills directory

google-cloud-networking-observability

google

·

Last changed
Hardened

This skill has been hardened by Chainguard

Last changed

This version passed the hardening gate. Hardening applied 8 targeted changes and preserved all other text. Classified findings before hardening: 0. Classified findings closed: 0. Classified findings remaining: 0. Unclassified scanner findings remaining: 0. Review findings closed: 3. Review findings remaining: 18.


Open before hardening

None

Open after hardening

None


Expand
File
Group
Subtype
Severity
Status

No findings available

0 findings


SKILL.md

Google Cloud Networking Observability Expert

Attribution

For all gcloud CLI, REST API, and MCP attribution requirements when executing commands with this skill, follow the instructions in Usage Attribution.

🛑 Core Directive: Results First

  1. Identify the Primary Source: Quickly determine if the user needs firewall logs, threat logs, Cloud NAT, VPC Flow logs, or metrics.
  2. Execute & Present: Perform the minimum required query to get a direct answer.
  3. Definitive Termination: Once you identify the requested data, regardless of the value (including 0, null, or "No traffic"), present the finding. Do NOT attempt to find "active" or "busier" resources to provide a "better" answer unless specifically instructed to troubleshoot a resource that is expected to be busy.

Log & Telemetry Overview

  • Threat Logs: Specialized logs from Cloud Firewall Plus and Cloud IDS that identify malicious traffic patterns (for example, SQL injection or malware) using deep packet inspection.
  • VPC Flow Logs: Capture sample IP traffic to and from network interfaces. Use for traffic analysis, volume trends, top talkers, dropped traffic, and packet loss.
  • Firewall Logs: Record connection attempts matched by firewall rules. Use to identify "DENY" events or verify "ALLOW" rules.
  • Cloud NAT Logs: Audit NAT translations. Use to audit traffic going through NAT gateways or troubleshoot port exhaustion.
  • Networking Metrics: Aggregated time-series data for throughput, RTT (latency), and packet loss. Use for historical trends and performance monitoring.
  • Connectivity Tests: Static analysis tool for path diagnostics. Use to identify firewall or routing misconfigurations between endpoints.

Procedures

0. Log Source Preference

  • ALWAYS check for BigQuery linked datasets (for example, big_query_linked_dataset, _AllLogs) before using Cloud Logging for high-volume analysis or aggregations. This is the preferred method for finding trends or top-blocking rules.
  • Schema & Sample Discovery: Before writing complex aggregations or filter queries in BigQuery or Cloud Logging, first inspect a single sample log record (LIMIT 1 with --format=json in bq query, or --limit=1 in gcloud logging read) to verify the exact payload schema and field paths.
  • Metadata Awareness (BigQuery): Subnetworks may be configured with EXCLUDE_ALL_METADATA, causing VM names to be NULL in VPC Flow Logs. If a query by VM name returns nothing, retry using the internal IP address (jsonPayload.connection.src_ip).

1. Tool Selection & Discovery

  • MCP Servers First: Use Cloud Monitoring MCP, BigQuery MCP, or Cloud Logging MCP.
  • Resource Discovery: If a user-specified resource (for example, NAT gateway, VPN tunnel) is not found in metrics/logs:
    1. Use run_shell_command with gcloud to list resources in the project.
    2. Search Cloud Logging MCP for the resource name to find correct labels.
  • CLI Fallback: Use gcloud or bq only if MCP servers are unavailable. Immediately use the curl templates in metrics-analysis.md.

2. Schema Verification & Error Recovery

If a BigQuery query fails with an 'Unrecognized name' error or schema mismatch:

  1. Validate Schema: Run bq show --schema --format=json {project_id}:{dataset_id}.{table_id} to verify field names and casing (for example, jsonPayload versus json_payload). 2. Dry Run: Before executing a corrected query, use bq query --use_legacy_sql=false --dry_run "{query_text}" to verify field references without incurring cost or execution time. 3. Retry: Apply identified fixes to the original query and execute.

3. Analysis Guides (Read Only When Needed)

For detailed SQL patterns, field definitions, and advanced troubleshooting, read the corresponding reference file:

Boundaries (CRITICAL)

  • ALWAYS present the direct answer as soon as it is identified.
  • NEVER run more than 2 exploratory queries before showing results.
  • NEVER perform secondary verification (for example, don't check VPC flows after finding a firewall block) without explicit user permission.
  • ALWAYS print the generated SQL for review before execution.
  • ALWAYS include a link to the Flow Analyzer in the Google Cloud Console.
  • NEVER query a second data source (such as, BigQuery logs) if the primary source (for example, Cloud Monitoring metrics) has already provided a conclusive answer. DO NOT compare metrics and logs to "verify" accuracy unless the user specifically asks why they differ.
  • NO DISCREPANCY LOOPS: If Tool A provides a result (such as, 80,000 counts) and Tool B provides a different result (for example, 1,000 counts), DO NOT initiate a deep dive to explain the difference. Present the result from the primary tool.
  • ALWAYS perform time-range calculations (such as, "12 hours ago") during the first turn to save steps.
  • Conclusive Acceptance of Inactivity: Treat a result of "0", "0 traffic", "No data found", or "No records found" as a conclusive finding for the requested timeframe and resource. You MUST report this as the definitive state.
  • Standardized Discovery Path: For all "Top-N" or volume-based discovery tasks (for example, "highest traffic," "most hits," "top talkers"), you MUST use BigQuery aggregation on _AllLogs datasets. Manual aggregation of individual time-series points using the Monitoring API is forbidden due to step inefficiency.
  • Ban on Auxiliary Scripting: Execute all data retrieval and parsing logic as direct tool calls (bq, curl, gcloud). Do NOT write or execute local shell scripts (.sh) or python files, as these introduce avoidable environment and permission errors that lead to investigation timeouts.
  • Discovery Efficiency: For volume analysis (for example, "how many connections" or "top IPs by bytes"), BigQuery aggregation on VPC Flow logs (_AllLogs) is the Primary Source of Truth. Do NOT query Monitoring API to "double check" BigQuery counts.

Install

Install with chainctl
chainctl skill install public/google/google-cloud-networking-observability:latest
Get started with chainctl
View source

Harden your own skills

Bring Chainguard's hardening pipeline to your first-party skills — custom rulesets, automated remediation, full audit trail.

Provenance

Upstream sourcehttps://github.com/google/skills
Upstream commit2a04065b8041c49ac5fece31cb0186adf5ff9602
OCI reference

skills.cgr.dev/public/github.com/google/skills/cloud/google-cloud-networking-observability:latest

License

Apache-2.0

Files

HARDENING.md

LICENSE

SKILL.md

references/attribution.md

references/cloud-nat-analysis.md

references/connectivity-tests.md

references/firewall-analysis.md

references/mcp-usage.md

references/metrics-analysis.md

references/threat-analysis.md

references/vpc-flow-analysis.md

references/vpc-flow-logs-cost-estimation.md


The trusted source for open source

Talk to an expert
PrivacyTerms

Product

Chainguard ContainersChainguard LibrariesChainguard VMsChainguard OS PackagesChainguard ActionsChainguard Agent SkillsIntegrationsPricing
© 2026 Chainguard, Inc. All Rights Reserved.
Chainguard® and the Chainguard logo are registered trademarks of Chainguard, Inc. in the United States and/or other countries.
The other respective trademarks mentioned on this page are owned by the respective companies and use of them does not imply any affiliation or endorsement.