Tenant Issue 9: Connectors Runtime Multi-Tenant Support

[christinaausley]

Review Stakeholders: @johnBgood @sbuettner @deepthidevaki

Links to Epics/Related Issues

• #3640 Physical Tenant - Multi-Tenant Connector Runtime and Java Client
• #3040 Centralized Secret Resolution via Zeebe
• #3430 Strong Tenant Isolation

Deliverables

• Connectors runtime multi-tenant overview page covering:
  • One runtime instance, multiple Physical Tenants
  • No separate deployment per tenant needed
  • Job worker registration per tenant
  • Authorization and secret isolation model
• Configuration guide covering:
  • Runtime registration with Orchestration Cluster
  • Tenant specification in runtime config (all or subset)
  • Secret resolution per tenant (centralized secret management)
  • Authentication headers/credentials for multi-tenant requests
• Outbound connectors documentation covering:
  • How connectors know which tenant triggered job
  • Tenant context propagation to external systems
  • Per-tenant secret access (API keys isolated per tenant)
  • Example: HTTP connector calling different endpoints per tenant
• Inbound connectors documentation covering:
  • Inbound connector path/routing strategy
  • How inbound webhooks routed to correct tenant
  • Known limitations for inbound connectors
  • Security implications of shared inbound endpoint
• Operational considerations covering:
  • Monitoring job execution per tenant
  • Secret rotation across tenants
  • Scaling strategy (one runtime vs multiple)
  • Failure handling and retry semantics per tenant

Context We Have

• One Connectors runtime can register job workers for multiple Physical Tenants
• Per-tenant secret isolation via centralized secret management (epic [DO NOT MERGE]: experimenting with version warnings, part 2 #3040)
• Outbound: per-tenant secret access, context-aware routing
• Inbound: routing/path strategy still being finalized
• No separate runtime deployment per tenant required
• Secret isolation dependency on epic [DO NOT MERGE]: experimenting with version warnings, part 2 #3040

Engineering Questions

1. How does Connectors runtime know which Physical Tenant a job came from? (Header injection, context variable, explicit configuration?)
2. For inbound connectors (webhooks), what is routing strategy to determine which tenant a request is for? (URL path, header, or other?)
3. If secret updated in centralized secret manager, does runtime refresh immediately, on next job, or on schedule?
4. For inbound connectors, what is recommended security model to prevent webhook from one tenant accidentally triggering job in another?