Integrating Two Companies Across GCP: Controlled Integration Boundary

Integrating Two Companies Across Separate GCP Environments: Building a Controlled Integration Boundary

When two companies need to integrate applications and data, the architecture challenge becomes significantly more interesting when both operate their own Google Cloud environments.

Consider:

Company A

  • Separate GCP Organization
  • Separate IAM
  • Separate VPCs
  • Separate security policies
  • Separate billing
  • Separate encryption keys

Company B

  • Separate GCP Organization
  • Separate IAM
  • Separate VPCs
  • Separate security policies
  • Separate billing
  • Separate encryption keys

The tempting solution is to connect the networks and start allowing traffic between them.

The better architectural principle is:

Do not integrate the environments. Integrate the services.

Treat the boundary between the two companies as a security boundary and introduce a Controlled Integration Boundary (CIB) through which cross-company communication occurs.

The Controlled Integration Boundary

Conceptually, the architecture looks like this:

             COMPANY A — GCP ORGANIZATION

      Applications
           |
           v
      Internal APIs
           |
           v
   Integration Services
           |
           |
=========== SECURITY BOUNDARY ===========
           |
           v
+-------------------------------------------+
|      CONTROLLED INTEGRATION BOUNDARY      |
|                                           |
|  Identity Validation                      |
|  Authentication                           |
|  Authorization                            |
|  API Gateway / Apigee                     |
|  Schema Validation                        |
|  Rate Limiting                            |
|  Data Filtering / DLP                     |
|  Threat Detection                         |
|  Logging / Audit                          |
|  Encryption                               |
+-------------------------------------------+
           |
=========== SECURITY BOUNDARY ===========
           |
           v
   Integration Services
           |
           v
      Internal APIs
           |
           v
      Applications

             COMPANY B — GCP ORGANIZATION

Instead of establishing broad trust between the organizations, we establish specific, measurable and revocable trust relationships between workloads.

This is essentially Zero Trust applied to enterprise integration.

1. Start With Identity, Not Networking

One of the first questions architects often ask is:

"How do we connect the two VPCs?"

A better first question is:

"Which workload in Company A needs permission to perform which action in Company B?"

Suppose Company A has an order processing application that needs to send orders to Company B.

Company A could have a workload identity representing:

order-service@company-a

Company B exposes an API:

POST /partner/v1/orders

The authorization rule becomes:

Company A
    |
    | authenticated workload
    |
    v
Company B Integration Boundary
    |
    | authorize:
    | order-service
    | POST /partner/v1/orders
    |
    v
Order Processing Service

The fact that traffic originated from Company A's network should not itself establish trust. The workload identity should establish trust.

Where practical, Workload Identity Federation can remove the need to exchange long-lived service account keys.

2. Build a Dedicated Integration Project

A useful implementation pattern is to create dedicated integration projects.

For example:

Company B GCP Organization
|
+-- Production
|
+-- Security
|
+-- Shared Services
|
+-- Partner Integration
       |
       +-- API Gateway / Apigee
       +-- Cloud Run integration services
       +-- Pub/Sub
       +-- Cloud Logging
       +-- Cloud KMS
       +-- Secret Manager

The partner integration project becomes a controlled landing zone for external workloads.

Company A never needs broad access to Company B's internal environment.

Instead:

Company A

     |
     | HTTPS / PSC / controlled connection
     v

Company B
Partner Integration Project

     |
     | tightly controlled internal access
     v

Company B
Production Services

This greatly reduces the blast radius of a compromised partner workload.

3. Put an API Control Layer at the Boundary

For synchronous integrations, APIs provide one of the cleanest boundaries.

An implementation might use:

Company A Application
        |
        | HTTPS
        v
External HTTPS Load Balancer
        |
        v
Cloud Armor
        |
        v
Apigee / API Gateway
        |
        v
Cloud Run Integration Service
        |
        v
Company B Internal Services

Each component performs a different security function.

Cloud Armor

Cloud Armor can provide:

  • WAF protections
  • IP restrictions where appropriate
  • DDoS protections
  • threat filtering

Apigee / API Gateway

The API layer can enforce:

  • authentication
  • JWT validation
  • OAuth
  • quotas
  • rate limits
  • API versioning
  • request policies
  • API analytics

Cloud Run

The integration service provides the actual business translation layer.

For example:

@app.post("/partner/v1/orders")
def create_order():

    identity = validate_identity()

    authorize(identity, "orders.create")

    request = validate_schema()

    clean_request = remove_disallowed_fields(request)

    internal_request = transform_to_internal_model(clean_request)

    order_id = submit_order(internal_request)

    audit_event(identity, order_id)

    return {"order_id": order_id}

The important point is that Company A's payload does not simply flow into Company B's production systems.

The integration layer validates and transforms it first.

4. Use an Anti-Corruption Layer

This also provides an important enterprise architecture benefit.

Company A might represent a customer as:

{
  "customerNumber": "12345",
  "givenName": "John",
  "familyName": "Smith"
}

Company B might use:

{
  "customer_id": "12345",
  "name": {
    "first": "John",
    "last": "Smith"
  }
}

Company B should not change its internal data model simply because Company A uses another format.

The integration service becomes an Anti-Corruption Layer:

Company A Schema
       |
       v
Controlled Integration Boundary
       |
       +-- Validate
       +-- Filter
       +-- Transform
       +-- Enrich
       |
       v
Company B Canonical Schema

This prevents partner-specific implementation details from leaking into the internal architecture.

5. Event-Driven Integration

Not every integration should use synchronous APIs.

For asynchronous workflows, Pub/Sub can provide a powerful integration pattern.

Consider Company A sending order events to Company B.

Company A

Order System
     |
     v
Integration Publisher
     |
     | authenticated publish
     v

============================
Controlled Integration Boundary
============================

Partner Pub/Sub Topic
     |
     v
Subscription
     |
     v
Validation Service
     |
     +---- Invalid ----> Dead Letter Topic
     |
     v
Transformation Service
     |
     v
Internal Pub/Sub Topic
     |
     v
Company B Applications

Notice that the partner does not necessarily publish directly onto Company B's internal event bus.

Instead, an external-facing topic receives the event.

The Controlled Integration Boundary then:

  1. Authenticates the publisher.
  2. Validates the event.
  3. Checks the schema.
  4. Rejects prohibited fields.
  5. Performs transformations.
  6. Records an audit event.
  7. Publishes an approved internal event.

This creates an important separation:

EXTERNAL EVENT

company-a.order.created

        ↓

CONTROLLED INTEGRATION BOUNDARY

        ↓

INTERNAL EVENT

enterprise.order.accepted

External events and internal events are not automatically equivalent.

6. Protect the Data Boundary

Cross-company integration is ultimately a data governance problem as much as a networking problem.

Suppose an API response contains:

{
   "customer_id": "98423",
   "name": "Jane Smith",
   "email": "[email protected]",
   "ssn": "123-45-6789",
   "account_balance": 24853
}

Company A may only be authorized to receive:

{
   "customer_id": "98423",
   "name": "Jane Smith",
   "account_balance": 24853
}

The integration layer therefore becomes a data enforcement point.

Sensitive fields can be:

  • removed
  • masked
  • tokenized
  • redacted
  • classified
  • logged

Google Cloud Sensitive Data Protection can also be incorporated into workflows where sensitive-data discovery, classification or de-identification is required.

The principle should be:

Crossing the organizational boundary requires explicit authorization not only for the API, but for the data itself.

7. Decide Who Owns Encryption Keys

Encryption becomes especially important when two independent organizations exchange sensitive information.

Three possibilities frequently appear.

Model 1

Company B owns data
Company B owns KMS keys


Model 2

Company A owns data
Company A controls encryption


Model 3

Shared integration

Company A Key
      +
Company B Key

The architecture should answer an important operational question:

What happens when the relationship between the companies ends?

Company B should be able to revoke Company A's access without redesigning its internal environment.

Identity, IAM permissions, APIs, network paths and encryption permissions should all have clearly defined revocation mechanisms.

8. Correlation IDs Become Essential

Distributed integrations become difficult to troubleshoot when each company maintains independent logging systems.

Every cross-company transaction should therefore carry a correlation ID.

For example:

X-Correlation-ID: 7d9127ab-91fd-4821

The same identifier follows the transaction:

Company A Application

7d9127ab
     |
     v
Company A Integration Service

7d9127ab
     |
     v
API Gateway

7d9127ab
     |
     v
Company B Integration Service

7d9127ab
     |
     v
Company B Application

Now both companies can investigate an incident without necessarily sharing their entire logging infrastructure.

Company A can report:

Transaction:
7d9127ab

Company B can search its own Cloud Logging environment for the same identifier.

9. Network Connectivity Is Still Important

Once identity and service boundaries have been established, the networking architecture can be selected.

Depending on the requirements, connectivity could include:

Internet + HTTPS
        |
        v
External Load Balancer

OR

HA VPN
        |
        v
Private connectivity

OR

Cloud Interconnect
        |
        v
Enterprise private connectivity

OR

Private Service Connect
        |
        v
Service-oriented private access

The decision should depend on:

  • security requirements
  • bandwidth
  • latency
  • regulatory requirements
  • application architecture
  • operational complexity

Private connectivity does not eliminate the need for workload authentication.

A private network is transport, not identity.

10. A More Complete GCP Implementation

Putting the pieces together gives us something like:

                     COMPANY A
                  GCP ORGANIZATION

              Order Application
                     |
                     v
             Integration Service
                     |
            Workload Identity
                     |
                     v

====================================================

              CONTROLLED TRUST BOUNDARY

                     |
                     v
              HTTPS / Private Access
                     |
                     v
               Cloud Armor
                     |
                     v
             Apigee / API Gateway
                     |
            JWT / OAuth Validation
                     |
                     v
               Cloud Run
          Integration Service
                     |
          +----------+-----------+
          |          |           |
          v          v           v
       Schema       DLP        Audit
      Validation   Checks       Logs
          |
          v
      Transformation
          |
          v
        Pub/Sub
          |
          v

====================================================

                     COMPANY B
                  INTERNAL TRUST ZONE

                Internal APIs
                     |
                     v
                Applications
                     |
                     v
             Databases / BigQuery

Additional controls can include:

Cloud KMS
   |
   +---- Encryption

Secret Manager
   |
   +---- Application secrets

Cloud Logging
   |
   +---- Audit trail

Security Command Center
   |
   +---- Security findings

VPC Service Controls
   |
   +---- Data perimeter controls

Cloud Monitoring
   |
   +---- SLO / availability monitoring

11. Terraform the Boundary

The Controlled Integration Boundary should ideally be infrastructure-as-code rather than a collection of manually configured resources.

A simplified repository might look like:

gcp-integration-boundary/

terraform/

  organization/
      org-policies.tf

  networking/
      vpc.tf
      firewall.tf
      private-service-connect.tf

  identity/
      service-accounts.tf
      workload-identity.tf
      iam.tf

  api/
      gateway.tf
      cloud-armor.tf

  integration/
      cloud-run.tf
      pubsub.tf
      dead-letter.tf

  security/
      kms.tf
      secrets.tf
      logging.tf

  monitoring/
      alerts.tf
      dashboards.tf

This is important because the integration boundary is a security control plane.

Changes should therefore be:

Architecture
     ↓
Terraform
     ↓
Pull Request
     ↓
Security Review
     ↓
Automated Policy Checks
     ↓
Deployment
     ↓
Audit Trail

A firewall rule or IAM permission connecting two companies should not quietly appear because somebody clicked a button in the console.

12. The Most Important Architectural Decision

The biggest mistake is treating two GCP organizations as though they were simply two VPCs belonging to the same enterprise.

Each organization represents a separate administrative and security domain.

The architecture should therefore look less like:

Company A VPC  <=================> Company B VPC

and more like:

Company A
   |
   v
Authenticated Workload
   |
   v
=============================
CONTROLLED INTEGRATION BOUNDARY
=============================
   |
   +-- Identity
   +-- Authorization
   +-- API Policies
   +-- Schema Validation
   +-- Data Controls
   +-- Encryption
   +-- Rate Limits
   +-- Logging
   +-- Monitoring
   |
   v
Company B

That distinction fundamentally changes the security model.

From Network Integration to Trust Integration

Historically, enterprise integration often started with networking:

Connect the networks and then determine what applications need access.

Cloud architecture gives us the opportunity to reverse that model:

Determine exactly which workloads need to communicate, establish their identities, authorize specific interactions, and then provide only the connectivity necessary to support them.

That is the real purpose of a Controlled Integration Boundary.