GCP Cloud Connector Security Guide

Security Guide

Overview

This guide helps customers deploy the GCP Cloud Connector with controls that fit sensitive PDF workflows. Use it together with the deployment guide and Cloud Storage setup.

Security Model

Understand the trust boundaries before deployment:

• The function exposes an HTTP API with no built-in application authentication or authorization.
• Clients submit Trusted Signatures credentials (apiKey, apiKeyId) in each POST /seal request.
• In Direct Mode, the PDF content also transits through the HTTP request body.
• In Storage Mode, the function reads and writes objects with its Google service account.
• The function only sends a SHA-256 digest to Trusted Signatures, but documents and API credentials still need protection inside your environment.

Because of that model, secure deployments should assume the function is a privileged internal service, not a public internet endpoint.

Hardened Baseline

Apply these controls for every production deployment:

1. Require authenticated invocation. Do not grant allUsers or allAuthenticatedUsers the invoker role unless you are intentionally publishing a public API and have compensating controls.
2. Use a dedicated service account for the function. Grant only the minimum Cloud Storage roles needed for the buckets and prefixes the function must access.
3. Prefer Storage Mode for sensitive or large documents. It keeps PDFs out of request payloads and lets you enforce bucket-level controls, CMEK, retention, and lifecycle policies.
4. Keep Trusted Signatures API credentials out of browsers and mobile apps. Call the function only from trusted server-side workloads or from an authenticated gateway that injects credentials securely.
5. Restrict ingress. Prefer internal callers, a private load balancer, API Gateway, or another trusted front door over a directly exposed public function URL.
6. Log metadata, not secrets. Do not enable request-body logging in proxies or client integrations that handle apiKey, base64 PDFs, or bucket paths containing sensitive identifiers.
7. Monitor and alert on invocations, permission failures, unusual volume, and writes to destination buckets.

Invocation Security

The function accepts any correctly formed request that reaches POST /seal. There is no tenant isolation, API key validation layer, IP filtering, or rate limiting in the application code. Enforce those controls in GCP:

• Require IAM-authenticated invocation for the Cloud Function.
• Grant roles/cloudfunctions.invoker only to approved service accounts or user groups.
• If multiple applications use the gateway, place a policy-enforcing service in front of it so callers do not invoke the function directly.
• Add rate limiting, authentication, and request validation in API Gateway, Apigee, a load balancer, or your own service tier when exposure beyond a tightly controlled backend is necessary.

Recommended pattern:

• Client application authenticates to your backend.
• Your backend authorizes the request and retrieves or injects Trusted Signatures credentials.
• Your backend invokes the Cloud Function with a service account identity.

Avoid this pattern:

• Browser or mobile app calls the Cloud Function directly with apiKey in the request body.

CORS and Browser Use

The function currently returns Access-Control-Allow-Origin: * and accepts cross-origin GET and POST requests. That makes browser-based invocation technically possible, but it should not be treated as a safe default.

If you expose this function to browsers:

• Any origin can send requests unless you add controls in front of the function.
• Trusted Signatures API credentials must be present in client-side code or delivered to the browser, which is usually unacceptable.
• Direct Mode sends the full PDF through the browser request path.

Recommended control:

• Do not expose the function directly to browsers. Put an authenticated backend or API gateway in front of it and restrict allowed origins there.

IAM and Service Accounts

Use a dedicated runtime identity for the function. Do not run it as the default compute service account.

Grant only what the function needs:

• roles/storage.objectViewer on the source bucket or a narrower scope if supported by your policy model.
• roles/storage.objectCreator on the destination bucket.

Do not grant broad roles unless required:

• roles/editor
• roles/owner
• roles/storage.admin
• Project-wide access when bucket-level access is sufficient

Operational guidance:

• Use separate service accounts for dev, staging, and production.
• Use separate buckets for each environment.
• Review IAM bindings regularly and remove dormant principals.

Secret Handling

The function does not read Trusted Signatures credentials from Secret Manager; it expects them in each request body. Treat that as a deployment constraint:

• Only trusted server-side workloads should send apiKey.
• Do not hardcode apiKey in frontend code, browser extensions, mobile apps, Terraform variables, or shell history.
• Store upstream application credentials in Secret Manager or your existing secrets platform.
• Ensure any gateway, proxy, or APM tooling in front of the function does not capture request bodies.

If you need stronger separation of duties, place a private service in front of this function that:

• Authenticates the caller
• Pulls the signing credentials from Secret Manager
• Invokes the function without exposing apiKey to the original client

Storage Mode Hardening

Storage Mode is the better production default when documents are sensitive or large.

Recommended controls:

• Use dedicated source and destination buckets for this workflow.
• Prefer bucket-level IAM over project-level IAM.
• Enable uniform bucket-level access.
• Enable retention or lifecycle policies based on your document handling requirements.
• Use object versioning only if your compliance model requires it.
• Configure CMEK if customer-managed encryption keys are required in your environment.
• Use distinct prefixes for each application or tenant and enforce naming conventions upstream.
• Prevent callers from overwriting important objects unintentionally by controlling destination object names in the calling service.

Operational caution:

• The function can read any object the service account can view and write any object it can create. Limit bucket scope so an invocation cannot be used to access unrelated data.

Network Controls

Default HTTPS transport protects data in transit, but network exposure still matters.

Recommended options, in order:

1. Keep the function private to trusted Google identities and invoke it from internal services.
2. Put API Gateway, Apigee, or a load balancer in front of it to add authentication, rate limiting, IP filtering, and WAF controls.
3. Use VPC connectivity only when required by your network policy; make sure egress still allows access to https://api.trusted-signatures.com.

If you restrict egress through a proxy or firewall, allow outbound HTTPS to the Trusted Signatures API endpoint or the sealing operation will fail.

Logging and Monitoring

The application logs sealing errors, but does not intentionally log request bodies. Your wider platform configuration still determines what may be exposed in logs.

Recommended controls:

• Disable or avoid request-body logging in API Gateway, load balancers, proxies, and client applications.
• Limit who can read Cloud Logging entries for this service.
• Create alerts for:
  • spikes in invocation count
  • repeated 403 or 404 responses
  • sudden increases in 5xx errors
  • unexpected writes to destination buckets
• Enable Cloud Audit Logs for Cloud Functions, IAM, Secret Manager, and Cloud Storage.
• Route audit logs to your SIEM or long-term retention platform if required by policy.

Deployment Checklist

Use this checklist before production go-live:

• Invocation requires authentication.
• No public invoker binding is present unless explicitly approved.
• The function runs as a dedicated least-privilege service account.
• Source and destination buckets are environment-specific.
• Cloud Storage permissions are bucket-scoped where possible.
• Request bodies containing apiKey or PDFs are not logged by upstream systems.
• Direct browser access is disabled or blocked.
• Monitoring, alerting, and audit logging are enabled.
• Egress to api.trusted-signatures.com is allowed.
• A rotation process exists for Trusted Signatures API credentials.

Shared Responsibility

Trusted Signatures protects the remote signing service. You remain responsible for securing:

• who can invoke the function
• where API credentials are stored before invocation
• Cloud Storage access in your project
• logging, retention, and monitoring settings
• network paths between your callers and the function

If you need stricter controls than this package supports directly, deploy the function behind your own authenticated service tier and keep the function URL inaccessible to end users.