Terraform scripts for deploying log export to Splunk per Google Cloud reference guide:
Deploying production-ready log exports to Splunk using Dataflow .

Resources created include an optional Cloud Monitoring custom dashboard to monitor your log export operations. For more details on custom metrics in Splunk Dataflow template, see New observability features for your Splunk Dataflow streaming pipelines.

These deployment templates are provided as is, without warranty. See Copyright & License below.

Deployment templates include an optional Cloud Monitoring custom dashboard to monitor your log export operations:

At a minimum, you must have the following roles before you deploy the resources in this Terraform:

• Logs Configuration Writer (roles/logging.configWriter) at the project and/or organization level
• Compute Network Admin (roles/compute.networkAdmin) at the project level
• Compute Security Admin (roles/compute.securityAdmin) at the project level
• Dataflow Admin (roles/dataflow.admin) at the project level
• Pub/Sub Admin (roles/pubsub.admin) at the project level
• Storage Admin (roles/storage.admin) at the project level

To ensure proper pipeline operation, Terraform creates necessary IAM bindings at the resources level as part of this deployment to grant access between newly created resources. For example, Log sink writer is granted Pub/Sub Publisher role over the input topic which collects all the logs, and Dataflow worker service account is granted both Pub/Sub subscriber over the input subscription, and Pub/Sub Publisher role over the deadletter topic.

The Dataflow worker service service account is the identity used by the Dataflow worker VMs. This module offers three options in terms of which worker service account to use and how to manage their IAM permissions:

1. Module uses your project's Compute Engine default service account as Dataflow worker service account, and manages any required IAM permissions. The module grants that service account necessary IAM roles such as roles/dataflow.worker and IAM permissions over Google Cloud resources required by the job such as Pub/Sub, Cloud Storage, and secret or KMS if applicable. This is the default behavior.

2. Module creates a dedicated service account to be used as Dataflow worker service account, and manages any required IAM permissions. The module grants that service account necessary IAM roles such as roles/dataflow.worker and IAM permissions over Google Cloud resources required by the job such as Pub/Sub, Cloud Storage, and secret or KMS key if applicable. To use this option, set dataflow_worker_service_account to the name of this new service account.

3. Module uses a service account managed outside of the module. The module grants that service account necessary IAM permissions over Google Cloud resources created by the module such as Pub/Sub, Cloud Storage. You must grant this service account the required IAM roles (roles/dataflow.worker ) and IAM permissions over external resources such as any provided secret or KMS key (more below), before running this module. To use this option, set use_externally_managed_dataflow_sa to true and set dataflow_worker_service_account to the email address of this external service account.

For production workloads, as a security best practice, it's recommended to use option 2 or 3, both of which rely on user-managed worker service account, instead of the Compute Engine default service account. This ensures a minimally-scoped service account dedicated for this pipeline.

For option 3, make sure to grant:

• The provided Dataflow service account the following roles:
  • roles/dataflow.worker
  • roles/secretmanager.secretAccessor on secret - if SECRET_MANAGER HEC token source is used
  • roles/cloudkms.cryptoKeyDecrypter on KMS key- if KMS HEC token source is used

For option 1 & 3, make sure to grant:

• Your user account or service account used to run Terraform the following role:
  • roles/iam.serviceAccountUser on the Dataflow service account in order to impersonate the service account. See following note for more details.

Note about Dataflow worker service account impersonation: To run this Terraform module, you must have permission to impersonate the Dataflow worker service account in order to attach that service account to Dataflow worker VMs. In case of the default Dataflow worker service account (Option 1), ensure you have iam.serviceAccounts.actAs permission over Compute Engine default service account in your project. For security purposes, this Terraform does not modify access to your existing Compute Engine default service account due to risk of granting broad permissions. On the other hand, if you choose to create and use a user-managed worker service account (Option 2) by setting dataflow_worker_service_account (and keeping use_externally_managed_dataflow_sa = false), this Terraform will add necessary impersonation permission over the new service account.

See Security and permissions for pipelines to learn more about Dataflow service accounts and their permissions.

• Terraform 0.13+
• Splunk Dataflow template 2022-04-25-00_RC00 or later

Before deploying the Terraform in a Google Cloud Platform Project, the following APIs must be enabled:

• Compute Engine API
• Dataflow API

For information on enabling Google Cloud Platform APIs, please see Getting Started: Enabling APIs.

1. Copy placeholder vars file sample.tfvars into new terraform.tfvars to hold your own settings.
2. Update placeholder values in terraform.tfvars to correspond to your GCP environment and desired settings. See list of input parameters above.
3. Initialize Terraform working directory and download plugins by running:

$ terraform init

Note: You can skip this step if this module is inheriting the Terraform Google provider (e.g. from a parent module) with pre-configured credentials.

$ gcloud auth application-default login --project <ENTER_YOUR_PROJECT_ID>

This assumes you are running Terraform on your workstation with your own identity. For other methods to authenticate such as using a Terraform-specific service account, see Google Provider authentication docs.

$ terraform plan
$ terraform apply

1. Retrieve dashboard id from terraform output

$ terraform output dataflow_log_export_dashboard

The output is of the form "projects/{project_id_or_number}/dashboards/{dashboard_id}".

Take note of dashboard_id value.

2. Visit newly created Monitoring Dashboard in Cloud Console by replacing dashboard_id in the following URL: https://console.cloud.google.com/monitoring/dashboards/builder/{dashboard_id}

The replay pipeline is not deployed by default; instead it is only used to move failed messages from the PubSub deadletter subscription back to the input topic, in order to be redelivered by the main log export pipeline (as depicted in above diagram). Refer to Handling delivery failures for more detail.

Caution: Make sure to deploy replay pipeline only after the root cause of the delivery failure has been fixed. Otherwise, the replay pipeline will cause an infinite loop where failed messages are sent back for re-delivery, only to fail again, causing an infinite loop and wasted resources. For that same reason, make sure to tear down the replay pipeline once the failed messages from the deadletter subscription are all processed or replayed.

1. To deploy replay pipeline, set deploy_replay_job variable to true, then follow the sequence of terraform plan and terraform apply.
2. Once the replay pipeline is no longer needed (i.e. the number of messages in the PubSub deadletter subscription is 0), set deploy_replay_job variable to false, then follow the sequence of terraform plan and terraform apply.

To delete resources created by Terraform, run the following then confirm:

$ terraform destroy

For those who require CMEK, this module accepts CMEK keys for the following services:

• Cloud Storage: see gcs_kms_key_name input parameter. You are responsible for granting Cloud Storage service agent the role Cloud KMS CryptoKey Encrypter/Decrypter (roles/cloudkms.cryptoKeyEncrypterDecrypter) in order to use the provided Cloud KMS key for encrypting and decrypting objects in the temporary storage bucket. The Cloud KMS key must be available in the location that the temporary bucket is created in (specified in var.region). For more details, see Use customer-managed encryption keys in Cloud Storage docs.

• Roy Arsan - rarsan
• Nick Predey - npredey
• Igor Lakhtenkov - Lakhtenkov-iv

Copyright 2021 Google LLC

Terraform templates for Google Cloud Log Export to Splunk are licensed under the Apache license, v2.0. Details can be found in LICENSE file.