Google Cloud Skills Tutorial — Part 3 : Advanced Ops: WAF Security + Reliability + Cost Optimization Assessment Skill
Welcome to the definitive guide on Google Cloud Agent Skills.
The Series:
– Part 1 : What are Google Cloud Skills
– Part 2 : Intermediate Skills in Action (BigQuery and Cloud Run)
– Part 3 : Advanced Ops (WAF Security + Reliability + Cost Optimization) (this blog)
– Part 4 : More Use Cases
For enterprise architects and senior engineers, skills go beyond basic provisioning. The Well-Architected Framework (WAF) skills turn your AI agent into a senior cloud consultant.
WAF Security Assessment
The google-cloud-waf-security skill executes a rigorous audit against Google's 7 core security principles (Zero Trust, Shift-left security, Preemptive defense, etc.).
The workflow is highly structured: the agent asks clarifying questions about your authentication, encryption, and network topology. It then maps your answers to GCP products (recommending Cloud Armor, KMS CMEK, or VPC Service Controls) and generates a SOC 2-ready compliance checklist.
Typically, a flow might go like this:
Let’s put things to the test now.
Important: You should execute this skill on an existing Google Cloud Project that you have, which is configured with gcloud and most importantly has several resources configured. This will give a chance to the skill to evaluate your project against multiple criteria and give you an assessment report.
In this step, we use the google-cloud-waf-security skill to perform an interactive security assessment of a Google Cloud workload. The agent acts as a security consultant, it asks targeted questions about your architecture, maps your answers against the Well-Architected Framework's security principles, and generates actionable recommendations.
What This Skill Does (and Doesn’t Do)
The google-cloud-waf-security skill is a guidance framework, not a live scanner. It does NOT run gcloud commands to inspect your infrastructure. Instead, it conducts a structured interview about your workload, evaluates your answers against Google's WAF security principles, and generates a tailored assessment with product recommendations and a validation checklist.
Think of it as having a Google Cloud security architect in a conversation with you, asking the right questions and giving expert advice based on your answers.
Confirm the Skill
Ensure the google-cloud-waf-security skill is installed:
npx skills list
If it’s not listed, install it:
npx skills add google/skills --skill google-cloud-waf-security
Updating the Skills
If you have installed the skills a while back, it is always a good idea to get the latest version of the skill. You can use the npx update command to update multiple skills in one short or even individual skills.
For e.g. you can use the following command to update an existing installed skill:
npx skills update <skill-name>
Prompt-Driven Security Assessment
Open your AI coding agent and work through the following prompts. You’ll describe a workload, and the agent will assess it.
Prompt 1 — Describe your workload
You prompt: I need a security assessment for a workload running on Google Cloud project YOUR_PROJECT_ID. The workload is an internal financial reporting dashboard. It uses Cloud Run to serve a Flask web app, Cloud SQL (PostgreSQL) for the database, BigQuery for analytics queries, and Cloud Storage for PDF report exports. The app is accessed by 50 internal employees. Evaluate this against the Well-Architected Framework security pillar.
What the agent does:
The output is comprehensive and long, so I will break it down into parts, so we can see the solid recommendations that have come in from the skill.
First up, is the following:
Well-Architected Security Assessment
Target Project: YOUR_PROJECT_ID
Workload: Internal Financial Reporting Dashboard
Components: Cloud Run (Flask Web App), Cloud SQL (PostgreSQL), BigQuery, Cloud Storage (PDF Exports)
User Base: 50 Internal Employees
Framework: Google Cloud Well-Architected Framework — Security Pillar
──────
## 1. Executive Summary & Assessment Overview
Financial reporting dashboards process highly sensitive corporate data subject to stringent confidentiality, integrity, and compliance requirements
(e.g., SOX, SOC 2, ISO 27001). Hosting an internal dashboard using default or publicly accessible configurations exposes the organization to
significant risk vectors including credential compromise, data exfiltration, injection attacks, and unauthenticated public exposure.
This assessment evaluates your architecture against the Google Cloud Well-Architected Framework (WAF) Security Pillar, covering Zero Trust, Network
& Perimeter Defense, Data Protection, Supply Chain / Shift-Left Security, and Operational Governance.
Next comes Security Gap Analysis and Risk Exposure (do scroll across to the right to see all the columns):
## 2. Security Gap Analysis & Risk Exposure
Architectural Layer │ Current Vulnerability / Risk Vector │ Severi… │ Recommended Remediation
─────────────────────────┼───────────────────────────────────────────────────────┼─────────┼────────────────────────────────────────────────────────
Authentication & Access │ Direct access to default *.a.run.app URL without │ CRITICA │ Require Identity-Aware Proxy (IAP) + Cloud Load
│ corporate IAM authentication │ L │ Balancing; lock down Cloud Run ingress to internal/LB
│ │ │ only.
Identity & Privilege │ Risk of using Default Compute Service Account or │ HIGH │ Provision dedicated, least-privilege Service Accounts
│ long-lived SA key files │ │ (SAs) using Workload Identity & short-lived tokens.
Database Connectivity │ Cloud SQL exposing a public IP address or accepting │ HIGH │ Enforce Private IP with Private Service Access /
│ unencrypted connections │ │ Serverless VPC Access Connector; require TLS & IAM DB
│ │ │ auth.
Data Exfiltration │ Unrestricted API endpoints for Cloud Storage and │ HIGH │ Enforce VPC Service Controls (VPC-SC) around BigQuery,
│ BigQuery across public internet │ │ Cloud Storage, and Cloud SQL.
Application Layer │ Potential SQLi, XSS, or SSRF attacks via Flask │ MEDIUM │ Deploy Google Cloud Armor with WAF OWASP rulesets; run
│ endpoints │ │ Flask via Gunicorn on distroless base images.
Export Bucket Security │ Potential public read/write access or missing object │ HIGH │ Apply Uniform Bucket-Level Access, prevent public
│ lifecycle/audit controls │ │ access, enable Customer-Managed Encryption Keys
│ │ │ (CMEK).
──────
Next is the Security Evaluation and Recommendations across IAM, Network Security & Perimeter Protection, Data Security & Encryption, Software Supply Chain Security, Operational Security, Logging & Threat Defense and Org Policy Constraints. Quite a comprehensive report to consider:
## 3. Detailed Security Evaluation & Actionable Recommendations
### 3.1 Identity & Access Management (Zero Trust)
│ [!IMPORTANT]
│ Because this application serves 50 internal employees, no unauthenticated or internet-facing endpoints should exist. Access must be strictly
│ identity-verified based on user identity and device context.
1. Deploy Identity-Aware Proxy (IAP):
• Route traffic through an External HTTP(S) Load Balancer or Internal HTTP(S) Load Balancer.
• Enable Identity-Aware Proxy (IAP) on the Backend Service with Google Workspace / Cloud Identity authentication.
• Enforce Context-Aware Access policies (e.g., requiring managed corporate devices or specific IP ranges via Chrome Enterprise Premium).
2. Restrict Cloud Run Ingress:
• Set Cloud Run ingress settings to Internal and Cloud Load Balancing.
• Remove allUsers and allAuthenticatedUsers from the roles/run.invoker IAM role. Grant roles/run.invoker only to the Load Balancer / IAP service
identity.
3. Least-Privilege Service Account Scoping:
• Do NOT use the default Compute Engine service account (PROJECT_NUMBER-compute@developer.gserviceaccount.com).
• Create a dedicated runtime service account sa-dashboard-runner@PROJECT-ID.iam.gserviceaccount.com with fine-grained IAM roles:
• Cloud SQL Client: roles/cloudsql.client
• BigQuery Data Viewer: roles/bigquery.dataViewer (restricted to dashboard datasets)
• BigQuery Job User: roles/bigquery.jobUser (project level)
• Cloud Storage Object Admin/Writer: roles/storage.objectAdmin (bound only to gs://PROJECT-ID-pdf-exports)
──────
### 3.2 Network Security & Perimeter Protection
<MERMAID_DIAGRAM_REPRODUCED_BELOW>
1. Egress via Serverless VPC Access:
• Configure a Serverless VPC Access Connector or Direct VPC Egress on Cloud Run to route egress traffic into a private subnet within your VPC.
2. Private Cloud SQL Instance:
• Disable Public IP on the Cloud SQL instance (sql.restrictPublicIp).
• Connect Cloud Run to Cloud SQL over Private IP using the Cloud SQL Auth Proxy connector integrated into the Flask app.
• Enforce SSL/TLS requirement for database connections (require_ssl = true).
3. VPC Service Controls (VPC-SC):
• Construct a security perimeter around project PROJECT-ID enclosing BigQuery, Cloud Storage, and Cloud SQL.
• Block unauthorized data exfiltration attempts even if credentials are breached.
4. Google Cloud Armor Protection:
• Attach Cloud Armor security policies to the HTTP(S) Load Balancer backend.
• Enable preconfigured WAF rules:
• sqli-v33-stable (SQL Injection protection)
• xss-v33-stable (Cross-Site Scripting defense)
• lfi-v33-stable (Local File Inclusion defense)
• Enable rate-limiting rules to prevent brute-force attacks or denial-of-service.
──────
### 3.3 Data Security & Encryption (At Rest & In Transit)
1. Customer-Managed Encryption Keys (CMEK):
• Create a Cloud KMS Key Ring in the matching region (e.g., us-central1).
• Encrypt BigQuery financial tables, Cloud SQL PostgreSQL disks, and Cloud Storage PDF export buckets using CMEK.
2. Cloud Storage Bucket Hardening:
• Set Uniform Bucket-Level Access (storage.uniformBucketLevelAccess).
• Enable Prevent Public Access (storage.publicAccessPrevention).
• Configure Object Lifecycle Management to auto-archive or purge sensitive PDF exports after 90 days.
• Enable Object Versioning to protect against accidental deletion or ransomware overwrites.
3. Sensitive Data Protection (Cloud DLP / SDP):
• Run automated Cloud DLP inspection jobs on BigQuery datasets and GCS export buckets to scan for sensitive identifiers (SSNs, credit card
numbers, bank routing info).
• Mask or pseudonymize PII columns in analytics views exposed to the Flask web UI.
──────
### 3.4 Shift-Left & Software Supply Chain Security
1. Hardened Container Configuration:
• Use minimal, hardened base images (e.g., distroless/python3 or python:3.11-slim).
• Run the Flask container under an unprivileged non-root user (USER nonroot).
• Avoid running Flask's built-in development server in production; serve via Gunicorn or uWSGI with appropriate worker process timeouts.
2. Artifact Registry & Vulnerability Scanning:
• Store container images in Google Cloud Artifact Registry.
• Enable Continuous Vulnerability Scanning (Container Analysis) to auto-detect CVEs in container layers.
3. Binary Authorization:
• Enforce Binary Authorization on Cloud Run to ensure only container images built, scanned, and signed by your CI/CD pipeline (e.g., Cloud
Build) can be deployed to production.
──────
### 3.5 Operational Security, Logging & Threat Defense
1. Security Command Center (SCC):
• Enable SCC (Premium or Enterprise tier) for project PROJECT-ID.
• Monitor SCC for active misconfiguration findings (e.g., IAM policy drift, public buckets, open database ports).
2. Audit Logging & PostgreSQL Auditing:
• Enable Data Access Audit Logs (Admin Activity, Data Read, Data Write) for BigQuery, Cloud Storage, and Cloud SQL.
• Enable the pgAudit extension on Cloud SQL PostgreSQL to log sensitive financial database transactions (SELECT, INSERT, UPDATE, DELETE).
3. Centralized Incident Response & Log Storage:
• Export audit logs to a locked, immutable log sink bucket with Object Lock / Retention policy for compliance compliance auditing.
──────
### 3.6 Organization Policy Constraints
Apply the following GCP Organization Policy constraints at the folder/project level:
• constraints/iam.disableServiceAccountKeyCreation: Prevent developers from generating service account .json key files.
• constraints/iam.allowedPolicyMemberDomains: Limit IAM policy bindings strictly to your corporate domain IDs.
• constraints/sql.restrictPublicIp: Block creation of public IP addresses on Cloud SQL instances.
• constraints/storage.uniformBucketLevelAccess: Mandate uniform bucket-level access across all storage buckets.
• constraints/run.allowedIngress: Restrict Cloud Run services to internal & load balancing ingress.
──────
Its even given a lovely diagram to understand its recommended architecture in the Network Security and Perimeter Protection:
It provides then a Priority Implementation Matrix as a diagram, which I have reproduced below. It definitely needs a bit of work with the rendering and placement of the text, but you get the picture.
Finally, there are some action items:
### Action Items Breakdown
1. Immediate (Days 1–3):
• Lock down Cloud Run ingress to internal-and-cloud-load-balancing.
• Configure HTTPS Load Balancer with Identity-Aware Proxy (IAP) and enforce MFA for all 50 internal users.
• Remove any service account .json keys; bind a dedicated runtime SA to Cloud Run.
• Enforce Uniform Bucket-Level Access and Prevent Public Access on the Cloud Storage bucket.
2. Short-Term (Weeks 1–2):
• Reconfigure Cloud SQL PostgreSQL to use Private IP only via Serverless VPC Access.
• Enable pgAudit on Cloud SQL and Cloud Audit Logs for BigQuery and GCS.
• Deploy Cloud Armor WAF policy with OWASP Top 10 rulesets.
3. Long-Term (Month 1):
• Implement VPC Service Controls (VPC-SC) perimeter for PROJECT-ID.
• Enable CMEK key management for data at rest.
• Integrate Binary Authorization and Artifact Registry vulnerability scanning into the CI/CD deployment pipeline.
Be Specific
In the above case, if you notice, you only provided some high level description and the skill evaluated your project against the WAF criteria based on that. This has its benefits since it will give you a broad and comprehensive list of things that your project can be evaluated against.
You can do a follow up to the above, by being more specific and providing details on your project setup and asking the WAF skill to evaluate and give some recommendations.
For e.g. you can do the following:
Based on the assessment framework you generated, here is my current setup:
1. We use the default compute service account for all services.
2. Cloud Run is publicly accessible with no IAP.
3. Cloud SQL has a public IP. We use Google-managed encryption only, no CMEK.
4. The data includes employee salary information (PII) with no masking.
5. Data Access audit logs are not enabled.
6. Security Command Center is not enabled.
6. Evaluate this against the criteria and tell me what passes and what fails.
The Agent gave me a response as follows (scroll to the right to see all the details). My current setup has failed on almost all the criteria.
Security Evaluation Against WAF Criteria
Target Project: PROJECT_ID
Workload: Internal Financial & Salary Reporting Dashboard
──────
## 1. Overall Pass / Fail Summary
# │ Assessment Criterion │ Security Pillar Requirement │ Your Current Setup │ Complia… │ Risk Severity
───┼───────────────────────────────┼────────────────────────────────────────────┼────────────────────────────────────────┼──────────┼───────────────
1 │ Application Access & Auth │ IAP + Cloud Load Balancer (Restricted │ Publicly accessible Cloud Run with no │ FAIL │ 🔴 CRITICAL
│ │ Ingress) │ IAP │ │
2 │ Identity & Privilege Scoping │ Dedicated Least-Privilege Service Account │ Default Compute Service Account used │ FAIL │ 🔴 CRITICAL
3 │ Database Network Isolation │ Private IP Only (VPC Access) + TLS │ Cloud SQL configured with Public IP │ FAIL │ 🟠 HIGH
4 │ Data Privacy & PII Handling │ Column Masking / Cloud DLP Inspection │ Employee salary PII unmasked in │ FAIL │ 🟠 HIGH
│ │ │ plaintext │ │
5 │ Audit Logging & Forensic │ Data Access Audit Logs + pgAudit enabled │ Data Access Audit Logs disabled │ FAIL │ 🟠 HIGH
│ Readiness │ │ │ │
6 │ Threat Monitoring & SecOps │ Security Command Center (SCC) Active │ Security Command Center disabled │ FAIL │ 🟡 MEDIUM
7 │ Data Encryption Control │ Customer-Managed Encryption Keys (CMEK) │ Google-Managed Keys only │ FAIL │ 🟡 MEDIUM
│ [!CAUTION]
│ Overall Assessment Score: 0 / 7 Criteria Passed (0%)
│ Your workload currently operates in a high-risk state. Internal financial and employee salary data is exposed to public internet access, over-
│ privileged permissions, and unmonitored data exfiltration risk.
──────
## 2. Deep-Dive Analysis of Failed Controls
### 🔴 FAIL 1: Publicly Accessible Cloud Run Without IAP (Critical Risk)
• Why it fails: Cloud Run is accessible directly over the internet without authentication.
• Security Exposure: Anyone who discovers or brute-forces your *.a.run.app URL can view company financial metrics and employee salary reports
without logging in.
### 🔴 FAIL 2: Using Default Compute Service Account (Critical Risk)
• Why it fails: The default compute service account (PROJECT_NUMBER-compute@developer.gserviceaccount.com) is assigned the broad roles/editor role
at project creation.
• Security Exposure: If an attacker exploits a web vulnerability in your Flask app (e.g., SSRF or Remote Code Execution), they inherit Editor
permissions across all resources in PROJECT-ID.
### 🟠 FAIL 3: Public IP on Cloud SQL Instance (High Risk)
• Why it fails: The PostgreSQL database port (5432) is exposed to the public internet.
• Security Exposure: Exposes database authentication to automated brute-force attacks, port scanning, and database zero-day vulnerabilities.
### 🟠 FAIL 4: Plaintext Employee Salary Data Without Masking (High Risk)
• Why it fails: PII and sensitive compensation data are retrieved and displayed in plaintext without role-based access control or dynamic data
masking.
• Security Exposure: Violates privacy compliance frameworks (SOC 2, GDPR, CCPA). Unauthorized internal employees or external attackers viewing
reports gain full visibility into individual employee salaries.
### 🟠 FAIL 5: Data Access Audit Logs Disabled (High Risk)
• Why it fails: BigQuery, Cloud SQL, and Cloud Storage read/write events are unmonitored.
• Security Exposure: You have zero forensic visibility. If salary data or financial reports are leaked or exfiltrated, it will be impossible to
identify who accessed the data, when it occurred, or what was taken.
──────
## 3. Immediate Emergency Remediation (First 24 Hours)
Execute these 3 emergency commands immediately to neutralize the highest critical vectors:
### 1. Lock Down Cloud Run Public Ingress
gcloud run services update DASHBOARD_SERVICE_NAME \
--ingress=internal-and-cloud-load-balancing \
--region=us-central1 \
--project=PROJECT-ID
### 2. Remove Unauthenticated Access
gcloud run services remove-iam-policy-binding DASHBOARD_SERVICE_NAME \
--member="allUsers" \
--role="roles/run.invoker" \
--region=us-central1 \
--project=PROJECT-ID
### 3. Enable Data Access Audit Logging for BigQuery & Cloud Storage
# Enable Data Access audit logs via gcloud
gcloud projects set-iam-policy PROJECT-ID policy.json
(Or enable Data Read / Data Write / Admin Read for BigQuery, Cloud SQL, and Cloud Storage under IAM & Admin -> Audit Logs in the Google Cloud
Console).
You might do further follow ups with prompts like the ones given below:
For the 3 most critical failures, give me the exact gcloud commands
I need to run to fix them.
Generate a SOC 2 readiness checklist based on the assessment.
The output received from the Agent for the SOC 2 readiness checklist is shown below:
SOC 2 Type II Readiness Checklist & Gap Analysis
Target Project: PROJECT-ID
Workload: Internal Financial & Salary Reporting Dashboard
Compliance Standard: AICPA SOC 2 Trust Services Criteria (Security, Confidentiality, Processing Integrity)
──────
## Executive Summary: Current SOC 2 Status
Based on your current environment state (default compute SA, public Cloud Run, public Cloud SQL, unmasked salary PII, and disabled audit logs), this
workload is currently NOT ready for a SOC 2 audit.
This checklist maps your required remediations directly to the SOC 2 Trust Services Criteria (TSC) and outlines the specific audit evidence you must
collect for your auditor.
──────
## 1. Logical Access Controls & Identity Management (CC6.1 – CC6.3)
SOC 2 Criteria │ Control Description │ GCP Implementation │ Curre… │ Required Audit Evidence
────────────────────────────────┼──────────────────────────────────┼───────────────────────────────────┼────────┼───────────────────────────────────
CC6.1 (User Authentication) │ Access to system resources is │ Enforce Identity-Aware Proxy │ ❌ GAP │ IAP access control lists, Google
│ restricted to authorized │ (IAP) + Cloud Load Balancing with │ │ Workspace MFA enforcement
│ workforce members with MFA. │ MFA mandatory via Google │ │ policies.
│ │ Workspace IDP. │ │
CC6.2 (Least Privilege Access) │ User and service privileges are │ Replace Default Compute SA with │ ❌ GAP │ IAM Policy exports (gcloud
│ granted based on least privilege │ dedicated sa-dashboard-runner │ │ projects get-iam-policy), Service
│ and job role. │ service account. Revoke │ │ Account binding definitions.
│ │ roles/editor. │ │
CC6.3 (Credentials Management) │ Long-lived static credentials │ Enforce Org Policy │ ❌ GAP │ Org policy constraint state, list
│ (API keys, service account JSON │ iam.disableServiceAccountKeyCreat │ │ of 0 service account .json key
│ keys) are prohibited. │ ion and use Workload Identity / │ │ pairs.
│ │ short-lived tokens. │ │
──────
## 2. Network & Boundary Defense (CC6.6 – CC6.7)
SOC 2 Criteria │ Control Description │ GCP Implementation │ Current S… │ Required Audit Evidence
─────────────────────────────────┼─────────────────────────────────┼─────────────────────────────────┼────────────┼─────────────────────────────────
CC6.6 (Boundary Protection) │ Perimeter controls prevent │ Set Cloud Run ingress to │ ❌ GAP │ Cloud Run service configuration
│ unauthorized external network │ internal-and-cloud-load- │ │ YAML, Cloud SQL network
│ access. │ balancing. Disable Cloud SQL │ │ configuration JSON.
│ │ Public IP. │ │
CC6.6 (Web Application │ Ingress web traffic is filtered │ Attach Cloud Armor WAF security │ ❌ GAP │ Cloud Armor policy
Security) │ against common web exploits │ policy with preconfigured SQLi │ │ configuration (gcloud compute
│ (OWASP Top 10). │ and XSS protection rules. │ │ security-policies describe).
CC6.7 (Data Exfiltration │ Data transmission boundaries │ Establish VPC Service Controls │ ❌ GAP │ Access Context Manager
Prevention) │ are established around │ (VPC-SC) perimeter enclosing │ │ perimeter definitions (gcloud
│ sensitive data stores. │ BigQuery, Cloud SQL, and Cloud │ │ access-context-manager
│ │ Storage. │ │ perimeters list).
──────
## 3. Data Confidentiality & Privacy Protection (C1.1 – C1.2, CC6.7)
SOC 2 Criteria │ Control Description │ GCP Implementation │ Curren… │ Required Audit Evidence
─────────────────────────────────┼──────────────────────────────────┼──────────────────────────────────┼─────────┼──────────────────────────────────
C1.1 (Data Classification & │ Confidential PII (salary info) │ Apply BigQuery Policy Tags / │ ❌ GAP │ BigQuery Data Catalog Policy
PII) │ is masked or restricted to │ Column-Level Security to mask │ │ Tags schema, DLP inspection scan
│ authorized roles. │ salary columns for unauthorized │ │ results.
│ │ roles. │ │
C1.2 (Data Encryption at Rest) │ Data at rest is encrypted using │ Configure Cloud KMS Customer- │ ❌ GAP │ KMS Key Ring configuration and
│ customer-managed cryptographic │ Managed Encryption Keys (CMEK) │ │ resource key binding outputs for
│ keys. │ for Cloud SQL, BigQuery, and │ │ all datasets/buckets.
│ │ GCS. │ │
C1.2 (Data Encryption in │ Data in transit across external │ Enforce require_ssl = true on │ ❌ GAP │ SSL/TLS certificate
Transit) │ and internal networks is │ Cloud SQL and HTTPS-only on │ │ configurations, database SSL
│ encrypted via TLS. │ HTTP(S) Load Balancer. │ │ connection enforcement logs.
CC6.7 (Storage Bucket │ Object storage is secured │ Set Uniform Bucket-Level Access, │ ❌ GAP │ GCS Bucket IAM policies (gcloud
Hardening) │ against public access and │ Public Access Prevention, and │ │ storage buckets describe
│ unauthorized modification. │ Versioning on GCS export │ │ gs://BUCKET).
│ │ buckets. │ │
──────
## 4. Monitoring, Logging & Incident Detection (CC7.1 – CC7.4)
SOC 2 Criteria │ Control Description │ GCP Implementation │ Curre… │ Required Audit Evidence
──────────────────────────────────┼──────────────────────────────────┼──────────────────────────────────┼────────┼──────────────────────────────────
CC7.1 (Vulnerability Management) │ Continuous threat and │ Enable Security Command Center │ ❌ GAP │ SCC vulnerability report
│ vulnerability monitoring is │ (SCC) and Artifact Registry │ │ exports, Artifact Registry
│ active across the environment. │ container vulnerability │ │ container scan reports.
│ │ scanning. │ │
CC7.2 (Audit Logging & │ Comprehensive audit logs capture │ Enable Data Access Audit Logs │ ❌ GAP │ Audit log configuration exports,
Monitoring) │ admin activity and sensitive │ (BigQuery, GCS, Cloud SQL) and │ │ Cloud Logging query samples
│ data access. │ pgAudit database extension. │ │ demonstrating log capture.
CC7.3 (Log Protection & │ Audit logs are stored immutably │ Configure Cloud Logging Sink to │ ❌ GAP │ Log Sink definition, Cloud
Retention) │ for compliance retention │ locked GCS bucket with Object │ │ Storage retention policy
│ requirements (e.g., 1 year). │ Lock retention policy. │ │ configuration (retentionPeriod).
──────
## 5. Auditor Evidence Collection Command Suite
When your auditor asks for evidence during your SOC 2 audit, run these gcloud commands to produce immutable JSON/YAML proof files:
# 1. Export IAM Policy (Proves least privilege)
gcloud projects get-iam-policy PROJECT-ID --format="json" > soc2_iam_policy_evidence.json
# 2. Export Cloud Run Configuration (Proves ingress restriction & SA attachment)
gcloud run services describe DASHBOARD_SERVICE_NAME --region=us-central1 --project=PROJECT-ID --format="yaml" >
soc2_cloud_run_evidence.yaml
# 3. Export Database Security Settings (Proves Private IP & SSL enforcement)
gcloud sql instances describe CLOUDSQL_INSTANCE_NAME --project=PROJECT-ID --format="yaml" > soc2_cloud_sql_evidence.yaml
# 4. Export Cloud Storage Security Policy (Proves Uniform Access & Public Access Prevention)
gcloud storage buckets describe gs://PROJECT-ID-pdf-exports --format="yaml" > soc2_gcs_bucket_evidence.yaml
# 5. Export Audit Log Configuration (Proves audit logging is active)
gcloud projects get-iam-policy PROJECT-ID --format="json(auditConfigs)" > soc2_audit_log_config.json
──────
## Next Steps to SOC 2 Audit Readiness
1. Remediation Execution: Implement Phase 1 & Phase 2 from the Remediation Plan to resolve all CRITICAL and HIGH gaps.
2. Audit Period (Observation Window): SOC 2 Type II requires a 3 to 6-month observation period during which all audit logging and controls must run
continuously without failure.
3. Internal Pre-Audit: Perform the automated verification script 30 days prior to audit engagement to confirm zero findings.
Key Takeaway (WAF Security skill)
The WAF security skill works in a two-phase pattern:
- Framework generation — The agent produces a structured evaluation criteria document customized to your workload type
- Tailored evaluation — You provide your actual configuration details, and the agent maps them against the criteria to produce specific pass/fail results and remediation steps
This gives you both the “what to check” and the “how to fix it” — the same deliverable a security consultant would produce, generated through natural language conversation.
Beyond Security: Other WAF Pillar Skills
Security is just one pillar of the Google Cloud Well-Architected Framework. The same interactive assessment pattern works with two additional WAF skills:
Cost Optimization — google-cloud-waf-cost-optimization
This skill generates cost optimization guidance for your workload. It evaluates your architecture against WAF cost principles and recommends ways to reduce spend.
npx skills add google/skills --skill google-cloud-waf-cost-optimization
Try this prompt:
Evaluate my financial reporting dashboard workload for cost optimization. It uses Cloud Run (always-on, 2 instances), Cloud SQL (db-standard-4, 100GB SSD), BigQuery (on-demand pricing, ~500GB scanned/month), and Cloud Storage (50GB Standard class). What are the biggest cost savings opportunities?
The agent will generate evaluation criteria around compute rightsizing, committed use discounts, storage tiering, and query optimization, then map your setup against them.
Here is a sample output:
Here is a cost-optimization evaluation for your financial reporting dashboard workload on Google Cloud, structured by cost impact.
──────
### Executive Cost Profile Summary
Service │ Current Config │ Approx. Estimated Monthly Spend │ Savings Potential
─────────────────────────────┼──────────────────────────────────────────────┼─────────────────────────────────┼─────────────────────────────────────
Cloud SQL │ db-standard-4 (4 vCPU, 15GB RAM) + 100GB SSD │ ~$290 – $310 / mo │ 🔴 High (30% – 50%)
Cloud Run │ Always-on, min-instances = 2 │ ~$60 – $90 / mo │ 🟡 Medium (40% – 70%)
BigQuery │ On-demand (~500 GB scanned/month) │ $0 / mo (within 1TB Free Tier) │ 🟢 Low (Focus on growth prevention)
Cloud Storage │ 50 GB Standard class │ ~$1.00 – $1.15 / mo │ 🟢 Low (Quick lifecycle fix)
──────
### 1. Cloud SQL Optimization (Largest Cost Saver: ~75-80% of total bill)
Cloud SQL db-standard-4 is likely your single largest cost driver.
• Rightsizing the Instance Size:
• Opportunity: A 4 vCPU / 15GB RAM instance is often over-provisioned for internal or scheduled reporting dashboards.
• Action: Check CPU and Memory utilization in Cloud Monitoring or GCP Active Assist Recommender. If average CPU utilization is <20-30%, downsize
to db-standard-2 (2 vCPU, 7.5GB RAM) or a custom shape (db-custom-2-7680).
• Estimated Savings: ~50% reduction in Cloud SQL compute cost (~$135–$145/month saved).
• Committed Use Discounts (CUDs):
• Action: If your database runs 24/7 and instance sizing is stable, purchase a 1-year or 3-year Committed Use Discount for Cloud SQL.
• Estimated Savings: 25% off for 1-year commit or 52% off for 3-year commit.
• Storage Sizing:
• 100 GB SSD costs ~$17/mo. SSD is recommended for transactional databases, but ensure Automatic Storage Increase is capped so log files or
temporary tables don't bloat storage indefinitely.
──────
### 2. Cloud Run Optimization (Medium Cost Saver)
Setting min-instances = 2 forces Cloud Run to keep 2 container instances running and allocated 24/7, forfeiting Cloud Run's native scale-to-zero
model.
• Time-Based Autoscaling / Scheduled Scaling:
• Observation: Financial dashboards are primarily accessed during business/trading hours. Paying for 2 instances at 3 AM or over weekends is
unnecessary.
• Action: Use Cloud Scheduler + Cloud Run API (or Terraform) to set min-instances = 2 during business hours (e.g., 7 AM – 7 PM weekdays) and
min-instances = 0 (or 1) off-hours.
• Estimated Savings: Reduces idle CPU time by 65%, saving **$40–$60/month**.
• CPU Allocation Model:
• If you currently use "CPU is always allocated", verify whether your app processes background tasks when no HTTP request is active. If not,
switch to "CPU allocated only during request processing".
• Concurrency Tuning:
• Check your concurrency setting (default is 80). Ensure your container runtime handles concurrent requests properly so a single instance can
absorb user traffic spikes before triggering extra instances.
──────
### 3. BigQuery Optimization (Cost Control & Speed Acceleration)
At 500 GB scanned per month, your BigQuery query costs are $0 because Google Cloud provides 1 TB per month of free on-demand query processing per
billing account.
• Preventing Future Cost Spikes:
• Use BigQuery BI Engine: BI Engine offers an in-memory acceleration service. The first 1 GB of BI Engine capacity is free, which can instantly
accelerate dashboard tile rendering without repeatedly querying raw tables.
• Partitioning & Clustering: Partition reporting tables by date (e.g., transaction_date) and cluster by frequent filter keys (e.g.,
department_id, account_id).
• Avoid SELECT *: Ensure dashboard SQL queries request only necessary columns to keep scan volume low as dataset size grows.
──────
### 4. Cloud Storage Optimization (Low Cost / Best Practice)
• Object Lifecycle Management:
• Financial reporting workloads often produce monthly PDF exports or CSV dumps. Standard Storage (50 GB) costs ~$1/mo, but applying lifecycle
rules prevents cost creep over time.
• Action: Configure a Lifecycle Policy to auto-transition objects older than 30 days to Nearline storage, and objects older than 90 days to
Coldline / Archive.
• Clean Up Incomplete Uploads: Add a lifecycle rule to delete incomplete multipart uploads after 7 days.
──────
### Actionable Implementation Checklist
1. 🔲 Audit CPU/RAM: Inspect Cloud SQL metrics; downsize to db-standard-2 if utilization is low.
2. 🔲 Schedule Cloud Run Min-Instances: Reduce min-instances to 0 or 1 during non-business hours.
3. 🔲 Reserve CUDs: Apply a 1-year or 3-year Committed Use Discount for Cloud SQL baseline compute.
4. 🔲 Enable BI Engine: Reserve 1 GB free BI Engine capacity for instant dashboard responsiveness.
5. 🔲 Set Up GCP Budget Alerts: Configure budget threshold alerts at 50%, 80%, and 100% of target monthly spend.
Reliability — google-cloud-waf-reliability
This skill assesses your workload against WAF reliability principles — availability, disaster recovery, scaling, and fault tolerance.
npx skills add google/skills --skill google-cloud-waf-reliability
Try this prompt:
Assess the reliability of my financial reporting dashboard workload. It runs on a single Cloud Run instance in us-central1, connects to a single Cloud SQL instance with no replicas, and stores critical PDF reports in a single-region Cloud Storage bucket. What are the reliability risks?
The agent will generate evaluation criteria around redundancy, failover, backup strategies, and SLA targets.
Here is a sample output:
Here is an evaluation of the reliability risks in your financial reporting dashboard architecture, based on the Google Cloud Well-Architected
Framework (Reliability Pillar).
──────
### Executive Risk Summary
Your current architecture contains 3 major Single Points of Failure (SPOF) across compute, database, and storage tiers. A failure at any single
layer will result in complete outage or data loss for your financial reporting dashboard.
[ Client Request ]
│
▼
[ Single Cloud Run Instance ] ⚠️ High Risk (No HA / Container Crash = 100% Downtime)
│
▼
[ Single Cloud SQL Instance ] 🔴 Critical Risk (Single Zone, No Failover Replica)
│
▼
[ Single-Region GCS Bucket ] 🟡 Medium Risk (No Multi-Region Redundancy / Versioning)
──────
### Key Reliability Risks
#### 1. Cloud SQL: Single-Zone & No High Availability (🔴 Critical Risk)
• Risk: Your database is running in a single Availability Zone without High Availability (HA) failover enabled.
• Operational Impact:
• Zonal Outage: If the primary zone housing your database suffers a hardware, power, or network issue, your dashboard is completely offline
until the zone recovers.
• Maintenance Outages: Google Cloud SQL performs routine maintenance and OS patches. Without HA, your database experiences mandatory downtime
during these maintenance windows.
• High RTO (Recovery Time Objective): Without a failover replica, recovering from an instance failure requires manual restoration from a backup,
leading to extended downtime.
#### 2. Cloud Run: Single Instance Constraints (⚠️ High Risk)
• Risk: Running a single container instance (max-instances = 1 or single active container) eliminates application-level redundancy.
• Operational Impact:
• Zero Fault Tolerance: If the container crashes (e.g., Out-Of-Memory during heavy PDF generation or an unhandled application exception), all
incoming user requests immediately fail (HTTP 502/503/504 errors).
• Resource Saturation: PDF generation is CPU/memory intensive. A single instance handling concurrent report generation requests can easily
saturate CPU/RAM, leading to severe latency spikes and HTTP timeouts.
• SLA Non-Compliance: Cloud Run's 99.95% Availability SLA relies on distributing traffic across multiple instances/zones.
#### 3. Cloud Storage: Single-Region & Data Loss Exposure (🟡 Medium Risk)
• Risk: Storing critical PDF reports in a single-region bucket (us-central1) without object protection exposes financial data to regional
disruptions and accidental deletion.
• Operational Impact:
• Regional Outage: If us-central1 experiences a region-wide issue, critical financial reports become completely inaccessible.
• Accidental Deletion / Overwrites: Without Object Versioning or Retention Policies, an application bug or user error could permanently
overwrite or delete historical financial reports.
──────
### Actionable Remediation Roadmap
To transform this into a resilient, production-ready enterprise architecture, implement the following prioritized recommendations:
#### Priority 1: Enable Cloud SQL High Availability (HA)
• Action: Upgrade your Cloud SQL instance configuration to High Availability (Regional).
• Benefit: Provisions a standby instance in a second zone within us-central1 with synchronous data replication. If the primary zone fails, Cloud SQL
automatically fails over to the standby instance in under 60 seconds without data loss.
• Backup Strategy: Ensure Point-in-Time Recovery (PITR) and automated daily backups are enabled.
#### Priority 2: Enable Cloud Run Autoscaling & Multi-Instance Sizing
• Action: Set min-instances = 2 (distributed across zones) and max-instances = 10+ (or higher depending on load).
• Benefit: Ensures zero downtime during container crashes or deployments, automatically absorbs traffic bursts during reporting periods, and meets
the GCP Service Level Agreement.
#### Priority 3: Protect Cloud Storage & Consider Dual-Region Storage
• Action:
1. Enable Object Versioning on the GCS bucket to protect against accidental deletion or corruption.
2. Enable Soft Delete (enabled by default in modern GCP buckets) to allow recovery of deleted files within a retention window.
3. Consider Dual-Region Buckets: For mission-critical financial reports, switch the bucket location from us-central1 to a Dual-Region
configuration (e.g., nam4: us-central1 + us-east1) for multi-region availability and failover.
#### Priority 4: Observability & Health Checking
• Action:
• Set up Cloud Monitoring Synthetic Checks or Uptime Checks against your Cloud Run endpoint.
• Define explicit Service Level Indicators (SLIs) and Service Level Objectives (SLOs) for dashboard response latency (< 2s) and availability (>
99.9%).
• Configure Alerting Policies on the 4 Golden Signals (Latency, Traffic, Errors, Saturation).
The Full WAF Assessment
For a comprehensive review, run all three assessments on the same workload:
Together, these three skills give you a holistic Well-Architected review, something that you would get from an experienced Google Cloud Architect.
The more specific you are about your current setup in the above prompts, the more actionable the agent’s recommendations will be. Include details about your IAM setup, network configuration, encryption choices, and monitoring tools.
In the next part of the article, we will look at a skill that helps us with Google Cloud Architecture. See you then.
Google Cloud Skills Tutorial — Part 3 : Advanced Ops: WAF Security + Reliability + Cost… was originally published in Google Cloud – Community on Medium, where people are continuing the conversation by highlighting and responding to this story.
Source Credit: https://medium.com/google-cloud/google-cloud-skills-tutorial-part-3-advanced-ops-waf-security-reliability-cost-7df63d15b96d?source=rss—-e52cf94d98af—4
About the Author
