[kaessert]

What

Adds identity.assumeRoleChainRef, so the STS assume-role chain can be resolved at runtime from a spec. / status. / context. path, the same way regionRef, filtersRef and parametersRef already work.

identity:
  source: PodIdentity
  assumeRoleChainRef: context.[apiextensions.crossplane.io/environment].awsQuery.roleChain

Why

identity.assumeRoleChain is static step input. When one Composition is deployed to many control planes and each control plane must query through a different role (e.g. one AWS account or business unit per control plane), the only option today is to bake the chain into the function pod's base identity (e.g. the Pod Identity association), which gives every composition on that control plane the same role. The ref lets platform-controlled config (an EnvironmentConfig) pick the role per control plane while the Composition stays identical.

Behaviour

• Path resolves → the list replaces the static assumeRoleChain; path absent → static chain is kept.
• Entries use the AssumeRole field names (roleARN required; externalID, roleSessionName, tags, transitiveTagKeys). They are decoded as strictly as the Input itself (exact names, unknown fields rejected), so a typo like externalId is fatal instead of silently accepted.
• Fatal, naming the ref and entry index: unrecognised prefix, non-list, empty list (would otherwise silently fall back to the base identity), non-object entry, missing roleARN, wrong field type.
• buildAWSConfig is unchanged; resolution happens next to the other resolve*Ref calls.
• README: field documented, plus a note to prefer a context. path fed from platform config over an XR spec. path, since the function's base identity is shared by every composition on the control plane.

Testing

• Unit: TestRunFunctionResolvesAssumeRoleChainRef — override from context, spec and status (all five fields), absent path keeps static, seven malformed cases are fatal and never reach the AWS query.
• crossplane render against a local STS stub: two-hop chains from context and spec produce the expected AssumeRole calls in order with all parameters, hop 2 signed with hop 1's credentials.
• crossplane render against real AWS (temporary IAM roles, since deleted), 7/7:
  • 2-hop chain from context and from spec, with a required ExternalId on hop 1 and a transitive session tag that a tag-conditioned policy on hop 2 requires → query succeeds as hop 2
  • same chain without transitiveTagKeys → UnauthorizedOperation as hop 2 (proves the tag is what made the positive case work)
  • wrong ExternalId → AccessDenied on hop 1
  • cross-account hop
  • ref path absent → static chain used
  • empty list → fatal before any AWS call
• Gate: go test ./..., golangci-lint v2.8.0 (0 issues), go generate + go mod tidy produce no diff.

[jakubramut]

Two findings:

1. an unresolved ref silently runs as the base identity - added as a separate comment
2. the PR touches nothing under example/ while last PRs #11 and #12 did.

[kaessert]

Thanks @jakubramut, both points addressed:

1. Unresolved ref without a static chain is now fatal: f958926 (details in the inline reply).
2. Examples, following feat: add new query types - DescribeRouteTables/DescribeSubnets/DescribeSecurityGroupRules #11/feat: adds a DescribeSecurityGroups queryType #12: 64d753a adds example/composition-assume-role-chain-ref.yaml (chain read from the environment context, as an EnvironmentConfig would supply it), a make render-assume-role ROLE_ARN=... target (kept out of make render like render-irsa, since it needs a role your creds can assume), and a section in example/README.md.

Verified with a real-AWS render: the cross-account role is assumed via the context value, and without the context value the step is fatal.

[jakubramut]

LGTM