Adds an optional `webIdentityTokenFile` field to
`AwsIntegrationAccountConfig` and `AwsIntegrationDefaultAccountConfig`.
When set on a per-account config along with a `roleName` and no static
credentials, `DefaultAwsCredentialsManager` now retrieves credentials
by calling `AssumeRoleWithWebIdentity` directly using the file's
contents as the web identity token (via `fromTokenFile`). The token
file is re-read on each refresh, so an external process can rotate it
in place — the same mechanism EKS IRSA uses, where the kubelet rotates
a projected service account token at the path identified by
`AWS_WEB_IDENTITY_TOKEN_FILE`.
This unlocks multi-account `AssumeRoleWithWebIdentity` for backends
running outside AWS (GKE, Cloud Run, Vault sidecars, etc.) without
requiring every plugin to construct a custom `AwsCredentialsManager`.
Existing call sites and configurations are unaffected — the new path
is opt-in via the new optional field.
Validator rejects:
- `webIdentityTokenFile` combined with static credentials
(`accessKeyId`/`secretAccessKey`) on the same account
- `webIdentityTokenFile` combined with `profile` on the same account
- `webIdentityTokenFile` without a `roleName` (matches the existing
precedent for `externalId`/`region`/`partition` without `roleName`)
- `webIdentityTokenFile` combined with `externalId` (the STS
`AssumeRoleWithWebIdentity` API does not accept an external ID)
Same rules apply at the `accountDefaults` level. The `!config.accessKeyId`
guard in `getSdkCredentialProvider` is defensive — it protects callers
that build an `AwsIntegrationAccountConfig` directly without going
through `readAwsIntegrationConfig`. In that case we fall through to the
existing static-creds AssumeRole path.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Signed-off-by: Brian Hudson <brian.r.hudson@gmail.com>
Brian Hudson
8df06ec2bc