UID2-4739: use DefaultCredentialsProvider for KMS client in JWTTokenProvider

[sophia-chen-ttd]

Summary

JWTTokenProvider explicitly constructs WebIdentityTokenFileCredentialsProvider for KMS access, which ties it to OIDC/IRSA. Switching to DefaultCredentialsProvider makes it compatible with EKS Pod Identity, instance profiles, and any future credential mechanism — matching the standard AWS SDK v2 best practice of letting the credential chain resolve at runtime.

• Replace WebIdentityTokenFileCredentialsProvider.create() with DefaultCredentialsProvider.create() in the non-static-credentials branch of getKmsClient
• Update the corresponding import

Companion fix to CloudStorageS3.java (UID2-4739).

Test plan

• Deploy to an EKS cluster using Pod Identity (not IRSA) and verify KMS signing succeeds
• Verify existing IRSA-based environments continue to work (DefaultCredentialsProvider falls through to the web identity token file provider in its chain)
• Verify static-credentials path (accessKeyId/secretAccessKey set in config) is unchanged

🤖 Generated with Claude Code

[sophia-chen-ttd]

The swap from WebIdentityTokenFileCredentialsProvider to DefaultCredentialsProvider is correct and aligns with AWS SDK v2 best practice. The change broadens credential chain support (IRSA, EKS Pod Identity, instance profiles, env vars, etc.) without affecting the static-credentials fast-path. No functional regressions are expected, but the expanded credential chain introduces some operational subtleties worth noting.

[sophia-chen-ttd]

Claude Review: DefaultCredentialsProvider.create() walks a multi-step chain on first call: env vars → system properties → web-identity token file → EKS Pod Identity → EC2 IMDS → ECS credentials. In a cold-start or misconfigured environment this can add latency (IMDS timeouts are 1 s by default, retried twice) before failing. Consider whether the KMS client construction path is latency-sensitive at startup; if so, add an inline comment naming the expected credential source so operators know what to look for when diagnosing slow starts.

[sophia-chen-ttd]

Claude Review: With WebIdentityTokenFileCredentialsProvider the IAM principal was always the IRSA service-account role — scope was predictable. With DefaultCredentialsProvider the resolved principal depends on the runtime environment (personal IAM user on a dev laptop, shared CI role, etc.). Confirm KMS key policies are updated to allow the new EKS Pod Identity role ARN, and that local/CI environments mock KMS or use a separate key.

[sophia-chen-ttd]

Claude Review: No unit tests appear to cover the non-static-credentials branch of getKmsClient (the else-branch changed here). Consider adding a test that passes a JsonObject without kmsAccessKey/kmsSecretKey and asserts the builder receives a DefaultCredentialsProvider, so a future regression would be caught by CI.