Automating Security and Centralized Logging

Automating infrastructure and application security means building vulnerability checks, admission control, hardened images, and policy guardrails into automated pipelines. In Google Cloud, Cloud Build builds images, Artifact Registry stores trusted images with scan metadata, Artifact Analysis stores vulnerability findings, and Security Command Center (opens in a new tab) monitors posture and runtime drift. Together they move security from manual review to enforced gates before deployment and continuous detection after deployment.

1.1Automated CVE Scanning in CI/CD Pipelines

Automated Common Vulnerabilities and Exposures (CVE) scanning checks container images and language packages for known vulnerabilities before they can be deployed. On-Demand Scanning scans images during the build before storage, Artifact Analysis stores vulnerability occurrences for images in Artifact Registry, and Cloud Build orchestrates the build, scan, gate, and push. Together they enforce a severity gate, produce triage data, and keep results fresh across rebuilds.

The build-to-registry flow runs in a fixed order with a hard stop on failure. First Cloud Build builds the container image from source code. Then On-Demand Scanning extracts operating system and language packages and versions and analyzes them remotely. Then a check step compares findings to the SEVERITY threshold, such as CRITICAL|HIGH which blocks on HIGH and the more severe CRITICAL findings. On success Cloud Build pushes the image to Artifact Registry with STATUS: SUCCESS, while on failure the step exits with non-zero status 1, later steps do not start, and no image is pushed.

Automatic scanning and On-Demand Scanning differ in when they run and where they block release. Automatic scanning monitors images after they are stored, while On-Demand Scanning blocks promotion before storage. Cloud Build depends on Artifact Analysis for results and on Artifact Registry to hold the trusted artifact and its scan metadata.

Triage sorts each vulnerability occurrence by identity, severity, and fix availability so owners know what to patch first. Artifact Analysis reports CVE name, effective severity and Common Vulnerability Scoring System (CVSS) score, fix status, affected package name and version, package type such as MAVEN, and affected location. Data flows from the scanner to Artifact Analysis occurrences, then from occurrences to the console for interactive triage with filtering and up to 1200 vulnerabilities per page, to the CLI with list-vulnerabilities and artifacts versions describe --show-package-vulnerability, or to the Container Analysis API with occurrence lists and project-wide vulnerabilitySummary totals. All three paths require permission to read scan metadata, including Artifact Registry Reader with Container Analysis Occurrences Viewer and Notes Viewer.

Scan freshness depends on pull activity. Artifact Analysis continues to refresh metadata only while the image or package has been pulled within the last 30 days. After 30 days without a pull, results become stale and are no longer updated, and after more than 90 days stale they become archived and can be evaluated only by using the API. Pulling a stale image restarts analysis, but refresh can take up to 24 hours, while stale packages cannot be rescanned until republished. Artifact Guard extends the gate into central policy with severity thresholds, package and CVE allow and deny lists, and temporary exception grace periods, enforced at build time in Cloud Build, at registry admission with Binary Authorization, and at runtime for Google Kubernetes Engine (GKE) containers in Security Command Center.

1.2Binary Authorization for GKE and Cloud Run

Binary Authorization is deploy-time admission control that decides whether a container image is allowed to run on GKE and Cloud Run. A Binary Authorization policy contains evaluation rules that allow an image, block an image, or require verified attestations from named attestors before deployment. At deploy time, traffic flows from the deployment request to the Binary Authorization enforcer, which checks the image digest against the matching rule and verifies required attestations before the platform starts the workload.

Deployment verification uses cryptographic proof that required checks already passed instead of re-running tests at deploy time. An attestation is a signed statement about a specific immutable image digest affirming that vulnerability scanning, testing, or build verification was completed. The signature binds the statement to the sha256: digest of the image manifest, so the same attestation authorizes identical images in Artifact Registry, Container Registry, or an external registry without a new signature. The sequence is fixed: first the pipeline builds an image with a unique digest, then an authorized identity signs IMAGE_PATH@IMAGE_DIGEST, then GKE or Cloud Run submits the digest for deployment, then Binary Authorization verifies all required attestations and the platform deploys only after success. Deploy with IMAGE_PATH@IMAGE_DIGEST, not mutable tags such as latest, because lookup happens only by digest.

An attestor is the Binary Authorization resource that represents a trusted authority, such as build-secure or prod-qa, allowed to vouch for images. Each attestor depends on an Artifact Analysis note that stores attestation metadata and on an asymmetric signing key that proves who created the attestation. Keys can be managed in Cloud Key Management Service (Cloud KMS), where Cloud KMS protects private material and Binary Authorization verifies with the public key, or as a local PKIX key file. The default rule applies to every workload without a more specific rule, and a new policy starts as allow-all until hardened. For GKE, cluster-specific rules can require attestations for production while the default stays permissive, and for Cloud Run enforcement is enabled per service so every new revision flows from service configuration to the enforcer.

Enforcement mode controls what happens when an image violates policy. In blocking mode the deployment is denied so only attested images run, while in dry-run mode the deployment is allowed but the violation is logged for testing. Exempt images bypass checks by image path, so any Pod referencing that path inherits the bypass and the list must stay narrow to registries under direct control. Break-glass is a per-workload annotation that bypasses an otherwise blocking policy for one emergency deployment, trading assurance for speed so access must be restricted and reviewed.

The automated signing workflow links a digest to its checks. The pipeline creates a JSON payload with gcloud container binauthz create-signature-payload, signs it with the private key, creates the attestation bound to digest and attestor, then lists attestations to confirm before deployment. Cloud Deploy adds approval between environments for GKE, while continuous validation extends the policy check through the Pod lifecycle by logging non-conformance in Cloud Logging when policy changes after deployment or when Pods used dry-run or break-glass. Changing to blocking does not stop already-running Pods, but validation surfaces them for remediation.

1.3Automated VM and Container Image Creation

Automated image creation keeps virtual machine (VM) and container images current, secure, and compliant without manual rebuilds. Cloud Build executes the image build, Artifact Registry stores the image with security metadata, and Cloud Scheduler starts rebuilds on schedule. Together they pull base-image fixes, operating system patches, and organizational policies into new images, then rotate old images out before they are used by mistake.

A scheduled rebuild pipeline is an automated chain where Cloud Scheduler sends an authenticated HTTP request to a manual Cloud Build trigger, and the trigger builds and publishes a fresh image. The workflow moves the image from built to stored to scanned to approved, and only the Cloud Build service account can push to the protected Artifact Registry repository, which enforces the trust boundary between mutable source and immutable output. The ordered pipeline is:

1. Store image: Create an Artifact Registry repository to hold the custom image and enable scanning.
2. Store configuration: Keep cloudbuild.yaml, imagebuilder.yaml, Dockerfiles, and scripts in GitHub connected to Cloud Build.
3. Create trigger: Create a manual Cloud Build trigger without push or pull-request filters.
4. Schedule execution: Create a Cloud Scheduler HTTP job on a cron schedule, such as 0 1 * * * for 01:00 daily.
5. Review results: Check build history in Cloud Build and vulnerability totals in Artifact Registry.

Two service-account dependencies must succeed. The account Cloud Scheduler acts as needs roles/cloudbuild.builds.editor to run the trigger, while the Cloud Build service account needs roles/artifactregistry.admin to upload the finished image.

Hardened baselines implement immutable infrastructure with strictly defined operating system, packages, users, and privileges. A VM baseline starts from a trusted source family such as ubuntu-2004-lts from ubuntu-os-cloud and adds only required software, while a container baseline starts from a pinned minimal base image and adds only required layers. Packer with Cloud Build produces hardened Compute Engine VM images using a template with project, image name, family, zone, googlecompute source, and shell provisioners that install approved packages and disable services. Image Builder further orchestrates customization, validation on a temporary test VM, and publication, depending on Virtual Private Cloud connectivity with Private Google Access, Cloud NAT for external packages, and firewall rules for debugging.

Automated patch management for long-running VMs is delivered by VM Manager Patch, which provides patch deployment for scheduling updates and patch compliance reporting for fleet visibility. A call to the VM Manager API notifies the OS Config agent to start patching, and the agent installs updates with the native tool for each distribution, including yum, apt, zypper, and Windows Update Agent. The service does not host packages, so each VM must reach its distribution source directly or through Cloud NAT, proxy, or local repository. Compliance reporting maps vendor data to Critical (RED), Important/Security (ORANGE), Other (YELLOW), and Up-to-date (GREEN). A patch job runs on demand across up to 500 VMs, while a patch deployment creates one-time or recurring jobs with up to 500 VMs per deployment, with runtime instance filters, maintenance windows, rollout limits, and reboot plus pre-patch and post-patch scripts.

Image lifecycle rotation groups related images, points users to the current version, and blocks stale versions. Compute Engine image families let deployments roll forward and roll back without hard-coding an image name, while administrators deprecate old images with gcloud compute images deprecate.

1.4Policy Enforcement and Drift Detection at Scale

Preventive and detective controls at scale block misconfigurations before creation and surface drift after deployment. The Organization Policy Service evaluates constraints at request time to prevent risky resources, while Security Command Center posture combines those constraints with Security Health Analytics detectors to define and monitor the known good state. Cloud Asset Inventory, Pub/Sub, and event-driven compute then carry change events to automation that remediates drift.

Custom organization policy constraints are user-defined rules that govern specific fields of supported resources with Common Expression Language (CEL) expressions. Managed constraints are predefined rules supplied by Google that enforce one fixed behavior. The request flows from the user or automation to the service API and then to the policy engine for an allow or deny decision, which prevents the misconfigured resource from existing rather than flagging it afterward.

Hierarchical inheritance flows from organization to folder to project to resource, so descendants inherit parent policy by default. Place broad baselines high for consistent posture and narrower constraints lower for single folders or projects. Conditional tag-based enforcement further scopes policy to only resources matching tags such as environment:prod.

The author-to-enforcement workflow rolls out a custom constraint safely through definition, attachment, simulation, and enforcement. The constraint definition, policy attachment, and enforcement mode are separate objects, which allows dry-run testing before blocking production. The ordered rollout is:

1. Define the custom constraint: Create the constraint in the organization with target resource, governed fields, and CEL condition that returns true for a violation.
2. Attach the organization policy: Bind the constraint to an organization, folder, or project node with inheritance and tag conditions.
3. Simulate impact in dry-run mode: Deploy in dry-run so the engine logs what would have been denied without blocking requests.
4. Enforce and validate: Switch to enforced mode and confirm compliant requests succeed while violating requests are denied.

A security posture in Security Command Center is one or more policy sets that enforce preventive and detective controls for a standard. A policy set groups policies for one regulation, a policy is a single constraint or detector, and a posture deployment applies the posture to an organization, folder, or project. Supported policies are Organization Policy constraints for prevention and Security Health Analytics detectors for detection. Real-time drift remediation connects inventory and findings to automation: Security Command Center reports drift as findings, Cloud Asset Inventory feeds emit asset change events, both flow through Pub/Sub to Cloud Functions or Cloud Run functions, the function reverts configuration or re-applies Terraform, and Security Command Center rescans and clears the finding when the resource matches again. Scale is bounded by 100 postures per organization, 400 policies per posture, and 1000 deployments per organization. Only one posture can be deployed to each organization, folder, or project, and when organization and project postures conflict, the lower-level posture controls that project.

Security Health Analytics custom modules are custom detectors that evaluate Cloud Asset Inventory metadata to generate findings for organization-specific misconfigurations. Custom modules run in Security Command Center Premium and Enterprise tiers and apply only to Google Cloud resources. Detection logic is a CEL expression that tests normalized asset metadata: when the expression matches, the engine creates a finding bound to that asset with category and severity, and when it does not match, no finding is produced. Deployment as code follows authoring YAML with CEL, targets, severity, and category, importing it to the parent resource, then enabling and validating. Remediation that makes the expression false allows the finding to move to inactive.

Configuring logging, monitoring, and detection means enabling the right audit and network sources, routing them centrally, protecting access, and turning findings into response. Logs flow from producing services to Log Router, then Log Router applies exclusions first and sink inclusion filters second, then matching entries flow from each sink to its destination. The design balances visibility, cost, retention, and least-privilege access.

2.1Network Log Configuration and Analysis

Configuring and analyzing network logs means combining firewall decisions, sampled flows, full-packet copies, and intrusion alerts in Cloud Logging for detection and forensics. Cloud Next Generation Firewall (Cloud NGFW) enforces policy inline and can block threats, while Cloud Intrusion Detection System (Cloud IDS) detects threats passively from mirrored traffic. VPC Flow Logs and Packet Mirroring provide traffic evidence, and Log Analytics makes all of it queryable with SQL.

Cloud NGFW and Cloud IDS differ in where they sit in the traffic path and how they respond. Cloud NGFW records which firewall policy rule allowed or denied traffic and, in Enterprise with intrusion detection and prevention, intercepts matched traffic for Layer 7 inspection. Traffic flows from VM instances or GKE clusters to firewall policy rules, then matched packets flow to a zonal firewall endpoint, then the endpoint scans for threat signatures and enforces the action. Cloud IDS works differently because mirrored traffic flows from Compute Engine VMs or GKE clusters to a Google-managed peered network, where Palo Alto Networks technologies inspect the copy. Cloud IDS endpoints in the Virtual Private Cloud (VPC) monitor ingress, egress, and intra-VPC traffic, including VM-to-VM east-west traffic that reveals lateral movement.

VPC Flow Logs and Packet Mirroring differ in granularity, cost, and forensic power. VPC Flow Logs samples packets sent from and received by VM instances, including GKE nodes and Direct VPC egress, and aggregates sampled flows by 5-tuple connection over an interval with byte and packet counts estimated for missed packets. Visibility is controlled by aggregation interval from 5 seconds to 15 minutes, secondary sampling from 1.0 to 0.0, metadata annotations, and filters. Packet Mirroring copies all packets with full payloads from source VMs to collector instances running third-party tools. Mirroring happens on the VM, not inline on the network. Use VPC Flow Logs for continuous monitoring of top talkers and inter-region flows, and use Packet Mirroring when investigation needs payloads such as HTTP detail or malware reconstruction.

Log Analytics turns distributed firewall, flow, DNS, and IDS logs into one queryable dataset. Data flows from VPC Flow Logs, Firewall Rules Logging, Cloud DNS (opens in a new tab) logging, and Cloud IDS into an upgraded Cloud Logging bucket with Log Analytics enabled, where the _AllLogs view exposes fields such as timestamp, resource.type, and json_payload. An aggregated sink routes organization, folder, project, and billing account logs to that bucket, to BigQuery for very large near real-time analysis, to Cloud Storage with optional Bucket Lock for immutable retention, or to Pub/Sub for SIEM ingestion. Correlation joins firewall decisions, flow 5-tuples, and IDS verdicts on time, IP addresses, ports, and protocol.

2.2Effective Logging Strategy Design

Designing an effective logging strategy means enabling the right audit and network sources, routing them through Log Router, and retaining them for analysis and compliance. Every entry arrives at Log Router, exclusions discard noise, and each sink forwards its inclusion-filter matches to its destination using a writer identity that must have destination permission. An aggregated sink created at the organization or folder collects from all current and future child projects into one central project outside workload-team control.

Critical log sources show who changed what and what traffic was allowed or denied. Cloud Audit Logs record control-plane and data-plane activity, while network logs record packet and rule decisions in the VPC. Most high-value sources require explicit enablement per subnet, rule, service, or organization policy. Key sources include Administrator Activity audit logs for configuration changes, Data Access audit logs for reads and writes to user data, VPC Flow Logs for subnet flows, Firewall Rules Logging for TCP and UDP ALLOW or BLOCK decisions, load balancer, GKE, Cloud Storage, Compute, and serial console logs, plus database statement logging and Workspace logs when in scope. Admin Activity logs are on by default, while Data Access, VPC Flow Logs, and Firewall Rules Logging must be explicitly enabled.

A practical pattern uses one aggregated sink that routes Admin Activity logs to a Logging bucket enabled for Observability Analytics, plus a second sink that routes Data Access logs from sensitive projects to Cloud Storage with retention locks. Centralized collection divides by use: centralized sinks to a central Logging or Storage bucket provide a tamper-separated record, direct ingestion to Google SecOps provides real-time multicloud correlation, and export to Pub/Sub or Storage then to Splunk or Elastic provides one central store across clouds. Log storage control decides region, duration, encryption, and access. Buckets are regional with custom retention from 1 day to 3650 days, default encryption is Google-managed, and customer-managed encryption keys (CMEK) in Cloud KMS control lifecycle. Log views hide entire LogEntry objects, while field-level access controls hide individual fields such as email addresses.

2.3Security Incident Logging, Monitoring, and Response

Logging, monitoring, and response in Google Cloud is an enable, route, analyze, and recover workflow that assumes an attacker is already inside. Cloud Logging ingests audit and network telemetry, an aggregated sink routes organization-wide copies to tamper-proof destinations, and analytics tools scan the centralized data for threats. Detection then drives containment, forensics, recovery, and program improvement.

Centralized audit coverage distinguishes customer admins from Google personnel. Cloud Audit Logs record who did what, when, and to which resource through identity, methodName, timestamp, request context, response, and service details. Admin Activity logs are on by default, while Data Access logs, token generation such as GenerateAccessToken, and service-specific platform logs must be enabled. Complete coverage adds VPC Flow Logs per subnet, Firewall Rules Logging per rule, Kubernetes and GKE audit logs, and Cloud IDS logs for north-south and east-west detections. Access Transparency provides near real-time logs of targeted Google personnel access, while Access Approval requires explicit customer approval before that access is permitted. Centralized destinations enforce immutability with Cloud Storage Bucket Lock, granular IAM read access, and optional VPC Service Controls perimeters around Storage, BigQuery, and Bigtable.

Continuous detection builds a baseline for normal behavior and flags deviations such as unusual protocols and sudden transfer spikes. Security Command Center enabled at the organization level with Premium tier centralizes findings, attack-path simulation, and compliance monitoring. Findings come from Security Health Analytics for misconfigurations, Event Threat Detection for near real-time log threats, Virtual Machine Threat Detection for malicious VM applications, Container Threat Detection for runtime container attacks, Cloud Run Threat Detection for serverless runtime, and Web Security Scanner for OWASP Top Ten issues. Event Threat Detection depends on enabled logs: Admin Activity is always scanned once enabled, while most Data Access and Workspace logs must be explicitly enabled first.

The formal data incident response lifecycle moves an event through ordered stages where each stage depends on the prior stage:

1. Identification and reporting: Automated and manual processes detect and report the issue.
2. Coordination triage: On-call responder assesses severity and assigns an incident commander.
3. Response team engagement: Commander designates leads and forms the response team.
4. Investigation: Team gathers facts and adds resources for expedient resolution.
5. Containment and recovery: Operations lead limits damage, fixes the cause, and restores service.
6. Communication: Communications lead evaluates notification need and develops the plan.
7. Closure and improvement: Team reviews the response, assigns owners, and improves protections.

For ransomware, the team activates the plan, confirms impact, opens a P1 case with Cloud Customer Care, quarantines infected systems first to limit lateral movement, restores from healthy backups or infrastructure as code, eradicates the vulnerability, then writes detection rules that would fire if the attack recurs.

2.4Secure Access to Logs

Secure access to logs controls which identities can query telemetry in Cloud Logging and from which context those queries succeed. Identity and Access Management (IAM) grants access from an identity to a log bucket or view, IAM Conditions and access levels add request context, and VPC Service Controls adds a network and resource perimeter. Together they separate operational logs from sensitive Data Access audit logs.

Predefined logging roles separate standard logs from private audit data in the _Default bucket. Logs Viewer grants read access to standard logs, Private Logs Viewer is additionally required for Data Access audit logs, Logs View Accessor grants access to specific log views, and Logging Admin manages buckets, sinks, and views. Least privilege grants only the needed role at the smallest scope, preferably to groups, with expiry, review, and 2-step verification. IAM Conditions make a valid role insufficient alone by evaluating time, resource name, IP address, geography, or device on every request. Access Context Manager defines an access level such as corporate network, and Chrome Enterprise Premium evaluates that level on each user API request to Cloud Logging.

VPC Service Controls perimeters enclose protected projects, Logging buckets, and supported APIs on the inside while untrusted networks and exfiltration destinations remain on the outside. Policies allow movement within the perimeter but deny reads, copies, or sink exports that cross the boundary without an explicit rule. The perimeter applies to all user and service account identities, so an automated exporter cannot bypass it. Segregation architectures isolate sensitivity by stream, entry, or field: log views isolate filtered subsets without new buckets, log sinks isolate full streams to separate project buckets, tags and IAM Conditions vary access by environment or context, and field-level access control hides specific fields while leaving the entry visible. A common pattern keeps operational logs in _Default for Logs Viewer access while a sink routes Data Access logs to a locked-down security project.

A custom log bucket is a regional Logging container with its own retention, location, and encryption policy. Retention is 1 day to 3650 days for all logs in the bucket, location is fixed for latency and residency, and encryption defaults to Google-managed keys with CMEK option. Field-level controls hide paths such as jsonPayload and leaf fields in textPayload, protoPayload, httpRequest, labels, and sourceLocation. Configuration uses gcloud logging buckets create or update with --restricted-fields, and update replaces the full set so all retained fields must be relisted. Queries in Logs Explorer omit denied fields, live tailing is unsupported, and a linked BigQuery dataset does not honor field controls.

2.5Log Export to External Security Systems

Exporting logs to external systems moves telemetry from Cloud Logging through sinks to Cloud Storage and then to Google Security Operations (Google SecOps), Splunk, Elastic, or other SIEMs. The pipeline depends on sink scope and filters, writer and reader identities, and storage protection working together. Every feed then normalizes raw logs into the Unified Data Model (UDM) for consistent detection.

An aggregated sink is a routing rule with scope, destination, inclusion filter, and optional exclusions. Project scope routes that project, while folder or organization scope aggregates all child projects into one destination. Data flows from Cloud Logging to the sink destination, then from the destination to the SIEM feed, so the destination must exist before routing starts. Inclusion filters select by resource.type, logName, and jsonPayload fields, and the effective export set is inclusion matches minus exclusion matches. New Cloud Storage sinks deliver hourly batches with 2 to 3 hours before first delivery.

Push and pull models define who initiates transfer and how fast events become searchable. Push sends events directly to the SIEM for low latency, while pull has SecOps poll staged storage to consolidate multicloud logs. Both normalize to UDM so identical behaviors from different clouds share one schema.

A secure pipeline separates a write-only logging identity, a read-only consumer identity, and a hardened bucket. The sink writer needs only Storage Object Creator, while the per-instance SecOps reader needs only Storage Object Viewer. Sink creation itself requires roles/logging.configWriter, so sink management, writing, and consumption remain distinct. The bucket uses Uniform access, public access prevention, Standard class for hot logs, and selectable encryption, location, versioning, and retention. Deletion options trade hygiene for evidence: Never preserves evidence with Viewer only, while Delete transferred files requires Object Admin and lets a misconfigured feed destroy the authoritative copy.

2.6Audit Log Configuration and Analysis

Configuring and analyzing audit logs turns Cloud Audit Logs entries into measurable signals, timely alerts, and forensic timelines. Cloud Logging collects and filters entries, Cloud Monitoring (opens in a new tab) evaluates alerting policies, and notification channels deliver incidents to responders and SIEMs. The goal is to record who did what, where, and when, then separate immediate threats from routine noise.

Audit log types differ by trigger and enablement. Admin Activity logs record configuration changes and are always written and cannot be disabled or excluded. Data Access logs record reads and data operations and must be explicitly enabled in the IAM AuditConfig object. Policy Denied logs record denials by security policy, and System Event logs record Google system actions without user action.

Each entry is an immutable LogEntry with protoPayload containing identity, methodName, timestamp, request context, response, and service details. Investigators fix the time window, filter by logName such as cloudaudit.googleapis.com/activity, by resource.type, and by methodName such as SetIamPolicy, then pivot across caller, IP, resource, and time. A log-based pipeline moves data in fixed order: first Cloud Logging filters entries into a metric or alert condition, then Cloud Monitoring evaluates the policy and fires an incident, then the incident flows to email, Pub/Sub, or dashboards. Dedicated filters should cover unauthorized compute creations, IAM grants, audit tampering, firewall openings, failed logins, anomalous key use, anomalous reads and exports, non-corporate accounts in privileged groups, and billing spikes.

2.7Log Sink and Aggregated Sink Configuration

Log export architecture is the controlled pipeline that moves telemetry from Cloud Logging through sink filters to Storage, BigQuery, Pub/Sub, or central Logging buckets. Entries that match the inclusion filter flow to the configured destination in hourly batches, land as sharded JSON organized by log type and date, then flow from the bucket to the feed reader. New Cloud Storage sinks can take 2 to 3 hours before first entries appear.

Bucket location determines where exported object data permanently resides. Location type of Region, Dual-region, or Multi-region plus a specific location controls geography, so regulated workloads select the location closest to the compliance boundary. Destinations divide by retention and use: Cloud Storage for low-cost retention and re-import, BigQuery for SQL analysis over date-partitioned tables keyed to entry timestamp, Pub/Sub for immediate ingestion, and a central Logging bucket for query-ready investigation without workload-project access.

An aggregated sink created at organization, folder, or billing account collects from that resource and all children. Organization scope collects all folders and projects, while folder scope collects only nested projects. Flow from children depends on --include-children, and the inclusion filter then selects Admin Activity, Data Access, or other logs. Routing copies rather than moves entries. A match is stored twice, once by child project sinks and again in the aggregated destination, so duplicates and cost continue unless child _Default sinks exclude centrally routed entries. System sinks guarantee local routing: _Required matches activity, system_event, and transparency entries and cannot be changed, while _Default matches all with empty inclusion and can be changed.

Filters decide whether an entry flows from sink to destination. A sink with no inclusion filter matches every entry, while exclusion filters override inclusion when both match. The governing rules are: no inclusion match means no routing, inclusion plus exclusion match means no routing, and inclusion without exclusion match means routing. Create and authorize an aggregated sink in order:

1. Create the sink: Run gcloud logging sinks create with destination, --log-filter, --organization, --include-children, and --use-partitioned-tables for BigQuery.
2. Verify creation: Run gcloud logging sinks list at the organization scope.
3. Retrieve the writer identity: Run gcloud logging sinks describe and copy the serviceAccount: value.
4. Grant destination write access: Grant that identity write permission, then confirm arrivals and control duplicates with child exclusions.

2.8Security Command Center Configuration and Monitoring

Security Command Center is the cloud risk platform that centralizes vulnerability detection, threat detection, posture management, and compliance monitoring. Findings are records of threats, misconfigurations, vulnerabilities, or drift created by built-in detectors, integrated Google services, and Marketplace partners. Architecture is controlled by service tier for capabilities and activation level for coverage scope.

Service tiers define available detection and operations capabilities. Standard provides basic misconfiguration scanning through Security Health Analytics, Premium adds threat detection, vulnerability detection, compliance, attack-path simulation, and posture management, and Enterprise adds SecOps SIEM and SOAR plus multicloud support. Enterprise is deprecated and will shut down on May 21, 2027, with automatic movement to Premium on or after that date.

Organization activation covers all folders and projects and is required for Enterprise, data residency, CMEK, and integrated sources, while project activation covers one project and never gains organization features even on Premium. First full scan completes within 24 hours. The four core services divide work by signal: Security Health Analytics reads configuration from Cloud Asset Inventory, Event Threat Detection applies intelligence to Logging streams, Container Threat Detection watches container runtimes for reverse shells and cryptominers, and Virtual Machine Threat Detection observes Compute Engine VMs from outside the guest OS. Event Threat Detection scans Admin Activity immediately but cannot scan Data Access or Workspace logs until they are enabled. Container Threat Detection needs supported GKE versions, and Cloud Run Threat Detection needs the API on every monitored project plus second-generation environment plus redeployment after enablement.

A threat finding names the affected resource, detector, and evidence needed to decide maliciousness versus misconfiguration. Review preserves evidence first, then context, then cause:

1. Open finding details: Examine Summary for context and JSON for complete fields.
2. Correlate related findings: Identify same-resource findings at similar times.
3. Review resource settings: Determine whether the change was authorized.
4. Check resource logs: Reconstruct who acted, from where, and what changed.

Operations filter with custom queries and mute rules, then establish real-time pipelines with Pub/Sub and Cloud Functions to route alerts, integrate SIEMs, and trigger remediation.

Key Facts

• On-Demand Scanning in Cloud Build enforces a severity gate where a match at CRITICAL|HIGH exits with non-zero status 1 and prevents the image push to Artifact Registry.
• Binary Authorization verifies attestations bound to the immutable sha256: digest before GKE or Cloud Run starts a workload, with a default rule that allows all images until hardened.
• Artifact Analysis stops updating metadata after 30 days without a pull and archives it after more than 90 days stale, with archived metadata available only through the API.
• Admin Activity audit logs are always written and cannot be disabled or excluded, while Data Access audit logs, VPC Flow Logs, and Firewall Rules Logging must be explicitly enabled.
• An aggregated sink copies logs from organization or folder children with --include-children and requires granting its writer identity destination write access; entries remain locally unless child _Default sinks add exclusions.