APPSINTG-160:GCP integration | Cloud Functions Integrations - Documen…

[shreyashnaik-sumo]

This PR introduces a new Google Cloud Functions integration (implemented via Cloud Run v2 service APIs that back 2nd-gen functions) and adds several actions plus accompanying pytest coverage.

Changes:

Adds the Google Cloud Functions integration definition with test-connection code and configuration fields for Secret (service account) and IAM/WIF authentication.
Implements actions to list/get services, trigger a service URL, monitor logs, and manage IAM policy / invoker access on the underlying Cloud Run service.

Select the type of change

• Minor Changes - Typos, formatting, slight revisions
• Update Content - Revisions, updating sections
• New Content - New features, sections, pages, tutorials
• Site and Tools - .clabot, version updates, maintenance, dependencies, new packages for the site (Docusaurus, Gatsby, React, etc.)

Ticket (if applicable)

https://sumologic.atlassian.net/browse/APPSINTG-160

[kimsauce]

You could add a short note to the "Trigger Function" action explaining how the invocation is authenticated and include a small example curl/payload so integrators know how to call 2nd-gen functions (Cloud Run v2 service URL).

Suggested wording to paste:

Trigger Function — Invokes the function by calling its Cloud Run v2 service URL. Authentication depends on the function's ingress settings:

• Public service: no Authorization header is required; you can call the service URL directly.
• Private service: include an identity/OIDC token for a service account that has the Cloud Run Invoker permission on the service.

Example — private service (obtain an identity token with gcloud and use it in the Authorization header):

TOKEN=$(gcloud auth print-identity-token)
curl -X POST "https://<SERVICE_URL>" \
  -H "Authorization: Bearer ${TOKEN}" \
  -H "Content-Type: application/json" \
  -d '{"example_key":"example_value"}'

Example — public service:

curl -X POST "https://<SERVICE_URL>" \
  -H "Content-Type: application/json" \
  -d '{"example_key":"example_value"}'

If the integration supports signing requests with service-account credentials (server-to-server), note that here and point to the integration configuration fields that must contain the service account or WIF credentials.

[kimsauce]

Possible suggestions... add a short "Troubleshooting" or "Common errors" section to help users debug WIF/service-account setup and common invocation issues. Suggested copy to paste:

Troubleshooting / Common errors

• Permission denied (401/403) on run.services.getIamPolicy or run.services.setIamPolicy

  • Cause: the service account used by the integration (or the impersonated account via WIF) lacks the required permissions.
  • Fix: grant the service account Cloud Functions Admin or a custom role containing cloudfunctions.functions.get, cloudfunctions.functions.invoke, run.services.getIamPolicy, and run.services.setIamPolicy. For invocations, ensure roles/run.invoker is granted to the caller principal.

• WIF pool / provider misconfiguration

  • Cause: incorrect AWS account ID, wrong aws_role ARN, or principal format mismatch in the Workload Identity Pool provider.
  • Fix: verify the provider is set to AWS, the Sumo Logic AWS account ID and role ARN are exact, and the principal is built as:
    principalSet://iam.googleapis.com/projects/{PROJECT_ID}/locations/global/workloadIdentityPools/{POOL_NAME}/attribute.aws_role/arn:aws:sts::{SUMO_AWS_ACCOUNT_ID}:assumed-role/{SUMO_AWS_ROLE}/{SUMO_AWS_LAMBDA}
  • Also confirm attribute mappings and audience settings in the pool match what Sumo Logic expects.

• Missing Google APIs (calls fail or setup steps not available)

  • Cause: required APIs are not enabled.
  • Fix: enable Cloud Functions API, Cloud Run API, Cloud Resource Manager API, IAM Service Account Credentials API, Security Token Service API, and Cloud Logging API for the project.

• Token or identity errors when invoking private services

  • Cause: using an expired or incorrect identity/OIDC token or not impersonating the correct service account.
  • Fix: generate a fresh identity token (e.g., gcloud auth print-identity-token when testing locally) or ensure the integration uses the configured WIF/service-account credentials to obtain tokens.

• Service ingress/network issues (function unreachable)

  • Cause: function or service ingress is restricted (internal VPC) or protected by IAM/ingress rules.
  • Fix: check Cloud Run/Function ingress settings, VPC connector configuration, and any firewall rules. For private services, ensure the caller has network access or use an authorized path.

• Where to check logs and diagnostically useful commands

  • Check Cloud Logging for Cloud Run and Cloud Functions logs to see error details.
  • Helpful commands:
    • Verify service IAM policy: gcloud run services get-iam-policy <SERVICE> --region=<REGION>
    • Test invocation (identity token): TOKEN=$(gcloud auth print-identity-token); curl -H "Authorization: Bearer $TOKEN" https://<SERVICE_URL> -d '{}'
  • If using WIF, check the Workload Identity Pool and provider logs and confirm that the SSO/token exchange succeeds.

• Next steps if still failing

  • Confirm the integration configuration JSON matches the selected auth type (WIF vs service account).
  • Link to relevant GCP docs (Workload Identity Federation, Cloud Run IAM, Cloud Functions auth) for deeper troubleshooting.

Feel free to shorten or localize any bullets — the goal is a compact section that surfaces the top, quick fixes users hit when configuring WIF/service-account auth or invoking Cloud Run v2-backed functions.

[kimsauce]

Reviewed the new Google Cloud Functions integration doc. CI is green (spellcheck/build/merge-window all pass), and most of the content correctly follows this directory's established patterns (reused Google Chat/Drive screenshots for generic GCP Console steps, misc/<slug>-configuration.png image path, Version/Updated block, Change Log format). Left inline comments on a few things worth addressing before merge:

1. Frontmatter deviates from the directory-wide convention (id + non-empty description where every neighboring doc uses neither).
2. Possible copy-paste residue in the WIF role/Lambda names — worth confirming with the backend owner that Cloud Functions actually shares Cloud Run's gcpiam role rather than having its own.
3. Missing permission in the least-privilege custom role list for the documented "Monitor Function Logs" action.
4. Minor: action name phrasing nit.

Nothing here blocks CI, but items 2 and 3 are functional/accuracy concerns worth confirming before publishing.

---

Generated by Claude Code

[kimsauce]

This frontmatter deviates from the established convention for this directory. I checked all 369 existing files under docs/platform-services/automation-service/app-central/integrations/ and every one of them uses title + description: '' with no id field:

---
title: <Name>
description: ''
---

This new file adds id: google-cloud-functions and a populated description, which is inconsistent with every neighboring doc in this directory. Suggest dropping id and setting description: '' to match.

---

Generated by Claude Code

[kimsauce]

This whole "Required Sumo Logic details for WIF authentication" block is word-for-word identical to google-cloud-run.md, including reusing the gcpiam role/Lambda suffix here.

Looking across the other GCP integration docs, role suffixes vary by integration where a dedicated backend exists (gcparmor, gcpcomposer, gcpservicemesh, gcpcompute, gcpgke), while a few others (pubsub, firestore, cloudsql-postgres) do legitimately share the generic gcpiam role with Cloud Run/IAM. Since this is a new integration with its own action set, can you confirm with whoever owns the backend Lambda/IAM role whether Cloud Functions actually shares Cloud Run's gcpiam role, or whether this got copy-pasted without updating to a Cloud Functions-specific role name? If it's wrong, customers following these WIF setup steps would grant access to the wrong role.

---

Generated by Claude Code

[kimsauce]

The least-privilege custom role permission list here (and the identical one at line 72) is:

cloudfunctions.functions.list, cloudfunctions.functions.get, cloudfunctions.functions.invoke, cloudfunctions.functions.update, run.services.getIamPolicy, run.services.setIamPolicy

But the Actions section documents a Monitor Function Logs (Daemon) action, and step 4 has users enable the Cloud Logging API. None of the listed permissions grant log-read access (e.g. logging.logEntries.list or an equivalent viewer-scoped permission). A customer who follows the least-privilege instructions as written wouldn't be able to use Monitor Function Logs even though they enabled the Logging API for it. Please add the missing logging permission to both lists (or confirm one of the existing permissions actually covers it).

---

Generated by Claude Code

[kimsauce]

Minor/non-blocking: "Enable Disable Function" reads a bit awkwardly — consider "Enable/Disable Function" for readability.

---

Generated by Claude Code