feat(aws): add support for externalId in AssumeRole for TriggerAuthentication

[zeevimeytar]

This PR adds support for passing an externalId when KEDA assumes an AWS IAM role via the TriggerAuthentication resource. The external ID is a security best practice for cross-account role assumption that prevents the "confused deputy" problem.

The externalId is specified as a field in spec.podIdentity, consistent with how roleArn is already modeled on AuthPodIdentity:

apiVersion: keda.sh/v1alpha1
kind: TriggerAuthentication
metadata:
  name: aws-trigger-auth
spec:
  podIdentity:
    provider: aws
    roleArn: "arn:aws:iam::123456789012:role/your-cross-account-role"
    externalId: "your-external-id-here"

The external ID is passed to AWS STS during the AssumeRole API call, which is required when assuming roles that have an sts:ExternalId condition in their trust policy.

Note: This PR supersedes #7388, which implemented the same feature using a metadata annotation (keda.sh/aws-role-external-id). Both PR authors are from the same organization. Based on the review feedback in #7388 — specifically @JorTurFer's request to use a spec field instead of an annotation for better alignment with existing configurations — this PR reimplements the feature as a first-class spec field. PR #7388 will not be continued and can be closed in favour of this one.

Changes

• Add ExternalID *string field (json:"externalId,omitempty") to AuthPodIdentity spec
• Add AwsRoleExternalID field to AuthorizationMetadata
• Map podIdentity.ExternalID to authParams["awsRoleExternalId"] in ResolveAuthRefAndPodIdentity
• Parse awsRoleExternalId from authParams in GetAwsAuthorization
• Include ExternalID in cache key generation to ensure separate cache entries per external ID
• Pass ExternalID to AssumeRoleOptions in retrievePodIdentityCredentials (pod identity path)
• Pass ExternalID to AssumeRoleOptions in GetAwsConfig (deprecated aws-eks path)
• Regenerate CRD manifests and deepcopy code
• Add unit tests for external ID parsing and cache key differentiation

Checklist

• When introducing a new scaler, I agree with the scaling governance policy
• I have verified that my change is according to the deprecations & breaking changes policy
• Tests have been added (if applicable)
• Ensure make generate-scalers-schema has been run to update any outdated generated files
• Changelog has been updated and is aligned with our changelog requirements, only when the change impacts end users
• A PR is opened to update our Helm chart (repo) (if applicable, ie. when deployment manifests are modified)
• A PR is opened to update the documentation on (repo) (if applicable)
• Commits are signed with Developer Certificate of Origin (DCO - learn more)

Fixes #

Relates to #7388

[snyk-io]

✅ Snyk checks have passed. No issues have been found so far.

Status	Scan Engine	Critical	High	Medium	Low	Total (0)
✅	Open Source Security	0	0	0	0	0 issues

💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse.

[github-actions]

Thank you for your contribution! 🙏

Please understand that we will do our best to review your PR and give you feedback as soon as possible, but please bear with us if it takes a little longer as expected.

While you are waiting, make sure to:

• Add an entry in our changelog in alphabetical order and link related issue
• Update the documentation, if needed
• Add unit & e2e tests for your changes
• GitHub checks are passing
• Is the DCO check failing? Here is how you can fix DCO issues

Once the initial tests are successful, a KEDA member will ensure that the e2e tests are run. Once the e2e tests have been successfully completed, the PR may be merged at a later date. Please be patient.

Learn more about our contribution guide.

[zeevimeytar]

Hey @JorTurFer, would appreciate your review here 😄

[zeevimeytar]

Happy to make changes here if required, @rickbrouwer 😃

[rickbrouwer]

Related with #6916 and #7665