Skip to content

refactor(cdk): collapse AgentSessionRole trust+grant into one admitComputeRole method #213

@krokoko

Description

@krokoko

Summary

Follow-up from PR #211 (per-session IAM scoping) code review. The AgentSessionRole construct exposes two methods that are two halves of one logical operation — admitting a compute role to use the SessionRole:

  • addAssumingRole(role) — adds the role to the trust policy (resource side)
  • grantAssumeToComputeRole(role) — adds sts:AssumeRole/sts:TagSession to the role's own policy (identity side)

AssumeRole requires both. Exposing them independently makes it possible to wire only one and get a role that is trusted-but-unreachable or reachable-but-untrusted, with no synth-time signal. The constructor also auto-trusts assumingRoles but does not auto-grant, so callers must remember the grant separately (see agent.ts and the ECS path, which call different combinations).

Proposed change

  • Collapse into a single admitComputeRole(role) that does both halves.
  • Have the constructor call it for each assumingRoles entry (so "admitted" always means fully wired).
  • Unify the trust-statement construction (constructor splits AssumeRole via assumedBy + a separate TagSession statement; addAssumingRole bundles both — make them consistent).
  • Keep a trust-only variant only if a cross-stack grantee genuinely needs it, clearly named as the exception.

Acceptance criteria

  • Single public method wires both trust + grant; call sites in agent.ts and ecs-agent-cluster.ts updated.
  • Constructor uses the same path (no auto-trust-without-grant asymmetry).
  • Trust-statement shape is consistent regardless of how a principal was added.
  • Existing tests updated; a test asserts both halves are present after one call.
  • mise //cdk:test + //cdk:synth pass; cdk-nag clean.

Context

Non-urgent — current code is correct (all three call sites wire both halves today); this is a footgun-removal / API-ergonomics hardening. Deferred from #211 to keep that PR focused.

Metadata

Metadata

Assignees

Labels

enhancementNew feature or request

Type

No type
No fields configured for issues without a type.

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions