[alongubkin]

Container workload roles trusted only the retained legacy node identity, so nodes using the isolation identity could not vend credentials and workloads failed at startup. Trust both exact stack-scoped node role ARNs while retaining the account condition and caller-side AssumeRole requirement. Privileged setup reconciles older workload-role checkpoints; runtime authority rejects saved trust/policy write states before IAM access.

Live AWS reproduction: old trust allows legacy nodes but denies isolated nodes. The candidate allows both node identities for newly created roles and for a preexisting legacy role repaired through the actual controller. An unrelated same-account node remains denied despite having its own caller-side AssumeRole grant. Every task-owned role is deleted and absence verified. Three focused tests also pass.

Legacy checkpoint validation deserializes the older JSON without the new optional field and converges through the existing controller states. Full generated Terraform and CloudFormation compute renders pass terraform fmt/validate and cfn-lint. Full workload startup on isolated nodes is not yet exercised end to end; the STS role-chaining proof above covers the trust change itself.

After merging main: the vault permission-update fixtures added by #932 now record the applied default trust policy, so ready roles are not scheduled for legacy trust repair (including the runner-owned role in the ignored live vault test). alien-infra service_account (15) and vault (31) tests and all alien-cloudformation tests pass.

Refs ALIEN-1316, ALIEN-1314

New controller state variants: AwsServiceAccountState::UpdatingStackPermissions and UpdatingResourcePermissions. Updates go UpdateStart -> UpdatingStackPermissions -> UpdatingResourcePermissions -> Ready, report Updating, and fail into UpdateFailed, so a failed policy write can't put a live role into CreateFailed, where the executor would replace it. Only privileged setup writes these states. Older binaries can't read them, so a checkpoint that stopped mid-update needs this version to resume. Create states are unchanged.

[enclave-ai]

Enclave skipped this draft pull request. It will run automatically when you mark the PR as Ready for review.

[greptile-apps]

Confidence Score: 5/5

[Critical risk] Changes IAM role trust policies for workload and compute node identities.

The PR appears safe to merge; no new actionable issue was established.

What we checked:

• Runtime cannot resume setup writes: The shared helper rejects frozen resources without direct setup authority before reaching IAM. It skips live resources.
• Trust repair has previous config: The executor saves the current config as previous_config before starting a planned update. This also covers updates requested by needs_update.

Summary

The PR adds exact isolation-node role names alongside legacy-node names in AWS workload trust policies. Privileged setup repairs older trust checkpoints, while runtime cannot resume setup-owned trust or policy writes.

• Update-specific permission states keep failed updates separate from failed creates.
• The live test cleans up every task-owned role, even after a lost create response.
• Vault fixtures now record their already-applied trust policy.
• Both previous, unnumbered findings are addressed.
• No new actionable issues were established. Tests and live AWS checks were not run during this review.

Diagram

%%{init: {'theme': 'neutral'}}%%
flowchart TD
  A[Privileged setup] --> B{Saved trust matches?}
  B -->|No| C[Update trust]
  C --> D[Update stack permissions]
  D --> E[Update resource permissions]
  E --> F[Ready]
  C -->|Failure| G[Update failed; keep live role]
  D -->|Failure| G
  E -->|Failure| G
  H[Runtime resumes a setup-owned write] --> I[Reject before IAM access]

Loading

_{Reviews (2) · Last reviewed commit: "refactor: keep service-account permissio..." · Reviewed by Greptile}