Modeling Real Architectures

In a multi-tenant API the deciding boundary is not the network edge but every endpoint, where an authenticated caller's tenant claim meets shared tenant-owned data. Information disclosure and elevation of privilege dominate the result.

Anything shipped inside an app package is readable by whoever holds a copy, so treat that key as public. Two assets are exposed: a fleet-wide credential an attacker can replay against your API, and the customer data cached on a device you do not own.

At your side of the tunnel. Everything arriving through it is untrusted input from a system you do not run, so the vendor stays outside your boundary even though the connection is private and encrypted.

Use the same four DFD elements: functions and managed-service calls are processes; buckets, tables and queues are data stores; event sources are external entities. Draw trust boundaries where the calling identity changes, not where a machine or network ends.

The node is the hard line, because pods on one node share its kernel, its disk and its credential. A namespace is an administrative scope the control plane enforces above the API, so it stops nothing that travels below it.

Treat the pipeline as the system: external entities (contributors, approvers, upstream registries), processes (trigger, build job, deploy job), stores (source repo, secret store, artifacts, runner disk). Put trust boundaries where trust actually changes — untrusted contribution entering the build, and the build reaching production credentials.

Put the trust boundary between the device and your API. Anything the client computes is an assertion, not a fact, so the server must re-derive the balance from state it holds. The client-side calculation is user-experience, not a control.

An anonymous contributor's first pull request becomes attacker-authored code running inside your trusted build with the production deploy credential in reach. The boundary between untrusted contribution and trusted build is in the wrong place: a secret-bearing job must not execute proposed changes.

Model the privileged routes as their own surface, with a boundary drawn inside the process and crossed where a handler decides a session may act with elevated rights. Elevation of privilege dominates the result, and record-changing flows add repudiation.

Model every process that reaches tenant-owned data, not just the HTTP handlers, and label each inbound flow with where its tenant identity comes from. A worker that reads the organization id from the message body is trusting caller-influenced data.

Model the update channel as an inbound flow crossing into the device, so the question is what the device verifies before accepting, not just how you authenticate it. A shared installer credential and a fleet-wide push make one compromise reach every unit at once.

Whatever the authenticated page contains: form fields, tokens in the DOM, personal data, anything typed. Script you include in your page runs with your page's privileges, so the vendor receives flows you never designed.

Whoever the queue's access policy permits to send can invoke the consumer with a payload of their choosing. The trigger binding is the only access control on that path, so an event source is an entry point like any public endpoint.

Model it as a component that sits inside every namespace boundary at once, not behind one. Its compromise does not cross boundaries, it erases them, so the threats worth listing are the ones that reach the component: its operators, and the tenant-writable input it acts on.

Repudiation above all: nothing binds a person to the release, so after a bad deploy nobody can establish who authorized it. Spoofing follows, because the webhook authenticates a call rather than an approver, and elevation of privilege if knowing the URL is enough to trigger a deploy.

Treat one deployment as three surfaces with three attacker populations, credential types and reachable operations, and model each separately. Unlisted internal endpoints on a shared listener are reachable, and a stolen machine credential is silent, long-lived and partner-wide.

Rate it by the union of everything the shared role can reach, not by how harmless each step looks: a compromise in the least significant step inherits the most sensitive grant. Fix it with per-step roles and a narrower handoff payload.

Treat it as a permanently open, authorized crossing from the operator zone into every member's account. Prevention is off the table without deleting the feature, so the model turns on scoping the capability and recording both identities on every action.

Accept that authorization happens on hardware you do not own and model the cost instead of denying it: stale revocation, duplicated passes, no global uniqueness check. Convert prevention into bounded loss plus reconciliation, and decide deliberately which way the gate fails.

Put the secret in the attacker's hands and re-read the diagram. A shared secret and an address allowlist authenticate a channel, not the truth of what it asserts, so treat partner events as claims and bound their financial damage.

Split when the tenants' threat models differ by more than the cluster can enforce: one tenant runs code nobody reviewed, the assets sit at very different values, or a shared control plane compromise is unacceptable. Otherwise separate node pools usually buy more than a second cluster.

Argue it as blast radius, not as taste. Letting the deploy job apply migrations means one merged file executes arbitrary statements against financial records with the pipeline's identity, reviewed by people who think they are approving code. Frame the choice as which authorities the deploy identity should hold.