Google Cloud (GCP) Integration: Creating the Required Credentials

Taylor Walton

07-Oct-2026

Google Cloud (GCP) Integration: Creating the Required Credentials

This guide walks you through preparing your Google Cloud environment so SOCFortress can collect your GCP logs into your SIEM. You'll create a place for your logs to be delivered (a Pub/Sub topic and subscription), route your logs there (a log sink), and create a dedicated service account with a key that our Wazuh platform uses to read them.

At the end there's a short test you can run yourself to confirm everything works before you send anything to us.

Time required: about 20–30 minutes.

What you'll send us at the end

Treat the JSON key like a password. Never send it over plain email. Upload it through the secure channel SOCFortress provides (for example, your OneHub folder).

Before you start

You'll need:

• Access to the GCP project with permission to create Pub/Sub topics, log sinks and service accounts, and to manage IAM. Project Owner, or an equivalent combination of admin roles, works.
• Either the Google Cloud console (console.cloud.google.com) or Cloud Shell / the gcloud CLI. Every step below shows both options.

Common blocker: some organizations block service account key creation with the organization policy iam.disableServiceAccountKeyCreation. If you get an error when creating the key in Step 6, your GCP organization administrator will need to allow key creation for this project.

In the commands below, replace these placeholders with your own values:

Step 1: Note your Project ID and enable the APIs

Console: your Project ID is shown in the project picker at the top of the console. Then go to APIs & Services > Libraryand make sure Cloud Pub/Sub API and Cloud Logging API are enabled.

gcloud:

gcloud config set project PROJECT_ID
gcloud services enable pubsub.googleapis.com logging.googleapis.com

Step 2: Create the Pub/Sub topic

The topic is where your logs are delivered.

Console:

1. Go to Pub/Sub > Topics and click Create Topic.
2. Enter the Topic ID (for example socfortress-wazuh-logs).
3. Leave Add a default subscription checked. This creates a subscription for you automatically.
4. Click Create.

gcloud:

gcloud pubsub topics create TOPIC_ID

Step 3: Create the pull subscription

The subscription is what our platform reads from. If the console already created a default subscription in Step 2, open it and confirm its Delivery type is Pull, then note its Subscription ID and skip ahead.

Console:

1. Go to Pub/Sub > Topics, select your topic, and click Create subscription.
2. Enter the Subscription ID (for example socfortress-wazuh-logs-sub).
3. Delivery type: Pull.
4. Message retention duration: 7 days is recommended. That gives us a buffer to catch up if collection is ever interrupted.
5. Click Create.

gcloud:

gcloud pubsub subscriptions create SUBSCRIPTION_ID \
 --topic=TOPIC_ID \
 --message-retention-duration=7d

Use this subscription only for SOCFortress. If anything else reads from it, those logs will never reach your SIEM.

Step 4: Route your logs to the topic (log sink)

The log sink tells Cloud Logging which logs to send to the topic.

Choose what to send

We recommend starting with Cloud Audit Logs. They cover who did what in your GCP environment and carry the most security value. Copy this inclusion filter exactly:

logName=~("projects/.*/logs/cloudaudit.googleapis.com%2F(activity|data_access|system_event|policy)")

Important: a sink with no filter exports every log in your project. That can be very large volume and cost. Always set an inclusion filter.

Optional additional sources. Add these to the filter (combined with OR) only if you want them, and coordinate with SOCFortress first:

Some of these logs have to be switched on at the source before they exist:

• Data Access audit logs are off by default for most services. Turn them on under IAM & Admin > Audit Logs. Be selective, because they can be high volume.
• DNS query logging is enabled per VPC network with a DNS policy:

  gcloud dns policies create POLICY_NAME --networks=NETWORK_NAME --enable-logging --description="SOCFortress DNS logging"
  

• VPC Flow Logs, Firewall Rules Logging and Load Balancer logging are each enabled on the subnet, firewall rule or backend service itself.

Create the sink

Console:

1. Go to Logging > Log Router and click Create Sink.
2. Sink details: enter a name (for example socfortress-wazuh-sink) and a description.
3. Sink destination: choose Cloud Pub/Sub topic and select your topic.
4. Choose logs to include in sink: paste the inclusion filter.
5. Choose logs to filter out of sink: leave empty unless you have known noise to exclude.
6. Click Create Sink.

gcloud:

gcloud logging sinks create SINK_NAME \
 pubsub.googleapis.com/projects/PROJECT_ID/topics/TOPIC_ID \
 --log-filter='logName=~("projects/.*/logs/cloudaudit.googleapis.com%2F(activity|data_access|system_event|policy)")' \
 --description="SOCFortress Wazuh log export"

Multiple projects? A project-level sink only exports that project's logs. To cover several projects with one sink, your organization administrator can create an aggregated sink at the folder or organization level (--organization=ORG_ID --include-children) that points to this same topic. Let us know if you go this route.

Step 5: Allow the sink to publish to the topic

Each sink has its own Google-managed identity (its writer identity), and that identity needs permission to publish to your topic. If you created the sink in the console with the topic in the same project, Google usually grants this automatically. Check it either way.

Find the writer identity:

• Console: Logging > Log Router, then the three-dot menu on your sink > View sink details. Copy the Writer identity. It looks like serviceAccount:service-123456789012@gcp-sa-logging.iam.gserviceaccount.com.
• gcloud:

  gcloud logging sinks describe SINK_NAME --format='value(writerIdentity)'
  

Grant it Pub/Sub Publisher on the topic:

• Console: Pub/Sub > Topics, select your topic, open the Permissions panel, click Add principal, paste the writer identity (without the serviceAccount: prefix), give it the Pub/Sub Publisher role, and save.
• gcloud:

  gcloud pubsub topics add-iam-policy-binding TOPIC_ID \ --member='WRITER_IDENTITY' \ --role='roles/pubsub.publisher'
  

  Use the full writer identity, including the serviceAccount: prefix.

A few minutes after this, logs should start flowing into the topic.

Step 6: Create the service account and JSON key for SOCFortress

This is the account our Wazuh platform uses to read from your subscription.

Console:

1. Go to IAM & Admin > Service Accounts and click + Create Service Account.
2. Enter a name (for example socfortress-wazuh) and a description, then click Create and Continue.
3. Add these two roles, as specified by Wazuh for the Pub/Sub integration:
   • Pub/Sub Subscriber
   • Pub/Sub Publisher
4. Click Done.
5. Open the new service account, go to the Keys tab, and click Add Key > Create new key > JSON > Create. The key file downloads to your computer. Keep it safe.

gcloud:

gcloud iam service-accounts create SA_NAME \
 --display-name="SOCFortress Wazuh integration"

gcloud projects add-iam-policy-binding PROJECT_ID \
 --member="serviceAccount:SA_NAME@PROJECT_ID.iam.gserviceaccount.com" \
 --role="roles/pubsub.subscriber"

gcloud projects add-iam-policy-binding PROJECT_ID \
 --member="serviceAccount:SA_NAME@PROJECT_ID.iam.gserviceaccount.com" \
 --role="roles/pubsub.publisher"

gcloud iam service-accounts keys create socfortress-wazuh-key.json \
 --iam-account=SA_NAME@PROJECT_ID.iam.gserviceaccount.com

The key is a JSON file containing fields such as "type": "service_account", "project_id", "private_key" and "client_email". Don't edit it.

Step 7: Test the credentials yourself

Run this from Cloud Shell or any machine with the gcloud CLI. It logs in as the new service account and reads from the subscription, which is exactly what our platform will do.

1. Upload the key (in Cloud Shell, use the ⋮ > Upload menu) and authenticate as the service account:

   gcloud auth activate-service-account --key-file=socfortress-wazuh-key.json --project=PROJECT_ID
   

   Expected: Activated service account credentials for: [socfortress-wazuh@PROJECT_ID.iam.gserviceaccount.com]

2. Generate some activity so there's an audit log to see. For example, open a few pages in the console or list your buckets.

3. Pull from the subscription. Do not add --auto-ack. Without it, the messages stay in the subscription and are still delivered to us later.

   gcloud pubsub subscriptions pull SUBSCRIPTION_ID --limit=5 --project=PROJECT_ID
   

4. Switch back to your own account when you're done:

   gcloud auth revoke SA_NAME@PROJECT_ID.iam.gserviceaccount.com
   gcloud config set account YOUR_USER_EMAIL
   

Reading the result

Only the first test (activation plus a pull with messages) needs to pass. You don't need any Wazuh software for this.

Step 8: Send the details to SOCFortress

Once the test passes, send us:

1. Project ID
2. Subscription ID
3. The JSON key file, uploaded through the secure channel we've provided (for example your OneHub folder), not by email
4. Which log types you enabled in the sink (audit logs only, or audit logs plus DNS/VPC/firewall/load balancer)

We'll configure the integration on our side and let you know once your GCP logs are visible in your SIEM.

Optional: Cloud Storage access logs

Wazuh can also read Cloud Storage usage and storage logs (bucket access logs) directly from a bucket. This is separate from the Pub/Sub method above and only covers bucket access logs. If you want it, let us know and we'll send the extra steps. In short: a log bucket with Cloud Storage logging enabled, and a service account with Storage Object User and Storage Insights Collector Service.

Good to know

• Cost: Pub/Sub and log routing charges appear on your GCP bill. A focused inclusion filter keeps them low.
• Key rotation: you can rotate the key at any time. Create a new key, send it to us securely, and delete the old key once we confirm we've switched over.
• Offboarding: to stop the integration, delete the sink and the service account key. Nothing on your side depends on SOCFortress beyond these resources.

Helpful documentation

Wazuh

• Monitoring Google Cloud with Wazuh (overview): https://documentation.wazuh.com/current/cloud-security/gcp/index.html
• Creating the service account and credentials: https://documentation.wazuh.com/current/cloud-security/gcp/prerequisites/credentials.html
• Google Cloud Pub/Sub (topic, subscription and log sink setup): https://documentation.wazuh.com/current/cloud-security/gcp/supported-services/pubsub.html
• Use cases and log filters (audit logs, DNS, VPC flow, firewall, load balancer): https://documentation.wazuh.com/current/cloud-security/gcp/supported-services/use-cases.html
• Google Cloud Storage buckets (access logs, optional): https://documentation.wazuh.com/current/cloud-security/gcp/supported-services/cloud-storage-buckets.html

Google Cloud

• Route logs to supported destinations (sinks and writer identity): https://docs.cloud.google.com/logging/docs/export/configure_export_v2
• gcloud auth activate-service-account reference: https://cloud.google.com/sdk/gcloud/reference/auth/activate-service-account
• gcloud pubsub subscriptions pull reference: https://cloud.google.com/sdk/gcloud/reference/pubsub/subscriptions/pull

Questions? Reply to your support case and we'll help.