Context
ADR-021's Lambda MicroVMs backend runs with deliberately relaxed IAM in two places, both proven necessary by controlled live experiments (evidence: ADR-021 §4 + docs/verification/645-p2-smoke-runbook.md):
- Role trust: the build, execution, and connector-operator roles trust
lambda.amazonaws.com with no aws:SourceAccount/aws:SourceArn condition — the service presents no source key when assuming them (conditioned trust → deterministic CREATE_FAILED / unassumable role).
- PassRole: the orchestrator's grant on the execution role and the bootstrap
MicrovmPassRoles statement carry no iam:PassedToService condition — the condition is denied on the RunMicrovm and CloudFormation paths (two-arm experiments, verbatim denials in the ADR). Candidate service principals (microvms.lambda.amazonaws.com etc.) were all implicitDeny, and CloudTrail emits no lambda-microvms events, so the value the authorizer would match cannot currently be observed.
Compensating controls in place: exact-ARN / name-prefix resource scoping, backend-conditional bootstrap policy, orchestrator-only pass path for the execution role.
Ask
When AWS documents (or the service starts presenting) usable condition keys for Lambda MicroVMs role assumption and PassRole:
- add the trust conditions back to all three roles
- restore
iam:PassedToService on both PassRole grants
- delete the compensating-control prose from ADR-021 §4 / SECURITY.md / DEPLOYMENT_ROLES.md
The ADR says "revisit if AWS documents it" — this issue is that revisit's handle. Consider also raising via internal AWS channels: the service team may simply need to publish the authorization-context documentation.
Refs #645, PR #733, ADR-021.
Context
ADR-021's Lambda MicroVMs backend runs with deliberately relaxed IAM in two places, both proven necessary by controlled live experiments (evidence: ADR-021 §4 +
docs/verification/645-p2-smoke-runbook.md):lambda.amazonaws.comwith noaws:SourceAccount/aws:SourceArncondition — the service presents no source key when assuming them (conditioned trust → deterministicCREATE_FAILED/ unassumable role).MicrovmPassRolesstatement carry noiam:PassedToServicecondition — the condition is denied on theRunMicrovmand CloudFormation paths (two-arm experiments, verbatim denials in the ADR). Candidate service principals (microvms.lambda.amazonaws.cometc.) were allimplicitDeny, and CloudTrail emits nolambda-microvmsevents, so the value the authorizer would match cannot currently be observed.Compensating controls in place: exact-ARN / name-prefix resource scoping, backend-conditional bootstrap policy, orchestrator-only pass path for the execution role.
Ask
When AWS documents (or the service starts presenting) usable condition keys for Lambda MicroVMs role assumption and PassRole:
iam:PassedToServiceon both PassRole grantsThe ADR says "revisit if AWS documents it" — this issue is that revisit's handle. Consider also raising via internal AWS channels: the service team may simply need to publish the authorization-context documentation.
Refs #645, PR #733, ADR-021.