Context
A managed cloud platform may need to inspect hundreds of customer accounts. That creates a deceptively simple question: when customer A requests a scan, what prevents the platform from scanning customer B instead? A valid AWS identity does not answer which customer's request the identity is serving. The account boundary and the application tenant boundary both need an explicit design.
Consider an illustrative monitoring service that accepts a role ARN during onboarding. An ARN identifies a resource; it does not prove that the person submitting it owns that resource. The useful security review starts at the onboarding form and follows the request through the worker, rather than stopping at a successful AssumeRole call.
What the external ID contributes
AWS recommends roles for delegating third-party access without sharing long-lived credentials. An external ID condition helps address the confused deputy problem: a trusted service is tricked into using its authority for the wrong customer. The provider should generate a unique external ID for each customer and require that value in the customer's role trust policy. An external ID is not a password or a replacement for a trusted principal. 1
Think of the role as a visitor badge and the external ID as the customer reference attached to the visit. The badge still needs an approved issuer, and the visitor still receives only the permissions written on it. Keep these responsibilities separate in diagrams, onboarding instructions, and reviews.
Trace identity through the application
Store the validated customer account ID, role ARN, external ID, and tenant identifier in a server-controlled onboarding record. A worker should obtain this record using its authenticated tenant context. It should not take the role ARN from an arbitrary job payload while taking the external ID from a different database lookup. Mixing individually correct fields can create an incorrect access decision.
Require the onboarding actor to demonstrate control using a documented verification flow before enabling scheduled scans. Record who approved access, when it was tested, and what permission set was expected. Treat a role ARN change as a meaningful configuration change with a new verification step. A convenient edit field should not bypass the original ownership check.
Build a test matrix that includes rejection
A successful scan proves very little about isolation. In a sandbox, exercise at least four combinations: customer A with A's role and external ID; A with B's role; A with an omitted external ID; and A with a deliberately incorrect external ID. The expected result is one permitted combination and explicit rejection for the others, subject to the intended trust configuration.
Also test the application API before the AWS call. A user belonging to A should be unable to edit B's onboarding record, enqueue B's account identifier, or retrieve B's scan results. AWS policy can be correct while a results endpoint leaks data. Capture request IDs and tenant IDs for the test, but never place temporary access credentials in the evidence bundle.
Limit the work the delegated role can perform
Start from a list of required API operations. A cost inventory service and a deployment service have very different needs. Separate observation from mutation where practical, and make write access an explicit product capability. Review resource scoping, service-specific conditions, and the consequences of permissions that cannot be narrowed to individual resources.
Avoid using administrative access to make the first integration test easier. That shortcut makes later failures harder to interpret because the test never exercised the intended permissions. Keep an example customer policy under version control and explain why each permission exists. When a new feature needs additional access, publish the policy difference and allow customers to evaluate it independently.
Make worker sessions and logs useful
Give work items stable identities so the same scan can be traced across an API request, a queue, and a worker. Record the selected customer account, assumed role ARN, operation class, and outcome. A session name can help investigations, but it is not an authorization mechanism and should not contain unnecessary personal information.
Plan for expired sessions and retried work. If a scan spans many accounts, checkpoint completed account-level work rather than repeating every account after one worker failure. Keep credentials in the credential provider's normal lifecycle. Do not serialize temporary credentials into job messages or report exports simply to make retries convenient.
Offboarding is part of the boundary
Disabling a customer in the portal should stop new jobs, cancel eligible queued work, and prevent new role sessions. Customer instructions should also explain how to revoke the role trust or remove the role. Account for already issued sessions when defining how quickly access must cease; a portal toggle alone should not be presented as immediate revocation of every existing session.
Preserve the minimum audit history required to explain previous activity, and apply the customer's data retention agreement to stored inventory. Access revocation and deletion of previously collected data are separate tasks with separate evidence. The closure record should show both when the contract requires both.
A focused operator exercise: An onboarding exercise with two customers
Create two isolated test tenants with different harmless inventory markers. Onboard each through the normal product flow, then submit a scan from the first tenant while attempting to substitute the second tenant's stored role reference. The application should reject the substitution before returning another customer's information. Repeat the check through both the interactive API and the queued worker path.
After disabling the first tenant, verify that no new scan is accepted and that eligible queued work is handled according to the offboarding policy. Record the remaining lifetime assumptions for sessions already issued. This exercise tests the customer boundary across the product rather than only the correctness of one IAM condition.
Quick diagnostic map
| Evidence | Review | Acceptance boundary |
|---|---|---|
| Tenant record | Match the authenticated tenant to its stored role | Reject cross-customer substitution |
| Role trust | Check the provider principal and external ID | Test omitted and incorrect IDs |
| Offboarding | Stop new jobs and role sessions | Record outstanding session assumptions |
Frequently asked questions
Does knowing the external ID grant access? No. The trusted principal, role policies, and relevant authorization controls still matter. The external ID supplies an additional context check.
What should a review demonstrate? Show the allowed workflow, rejected cross-customer combinations, scoped permissions, and an exercised offboarding procedure. Those results turn an IAM configuration into an understandable operating boundary. Clouvenix can use this evidence to review a multi-account management design before wider onboarding.
For a scoped review of this workflow, discuss the relevant Clouvenix engineering service.