feat(aws-sqs): Add external ID support for cross-account access

[tangobango5]

This commit adds support for external ID in AWS SQS scaler to enable secure cross-account access scenarios. External ID is now parsed from TriggerAuthentication and passed to STS AssumeRole operations.

Changes:

• Add AwsExternalID field to AuthorizationMetadata struct
• Update GetAwsAuthorization to parse external ID from auth parameters
• Modify cache key generation to include external ID
• Update AssumeRole providers to use external ID when available
• Add comprehensive test coverage for external ID scenarios

The external ID is only used with AssumeRole operations and maintains backward compatibility with existing configurations.

Provide a description of what has been changed

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
• Changelog has been updated and is aligned with our changelog requirements
• 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 # #6921

Relates to #

[JorTurFer]

Awesome improvement! ❤️
As this is part of pod identity (IRSA role assumption), WDYT if we set it as a new parameter in trigger authentication? This would make the new feature available for any AWS Scaler at once.

Please, also open a PR to docs to document the new parameter

[zroubalik]

Awesome improvement! ❤️ As this is part of pod identity (IRSA role assumption), WDYT if we set it as a new parameter in trigger authentication? This would make the new feature available for any AWS Scaler at once.

Could you please elaborate here?

[JorTurFer]

Awesome improvement! ❤️ As this is part of pod identity (IRSA role assumption), WDYT if we set it as a new parameter in trigger authentication? This would make the new feature available for any AWS Scaler at once.

Could you please elaborate here?

sure, AwsExternalID is part of the auth SDK and not from SQS SDK. The OP has added the parameter to the SQS trigger but it's passed directly to the auth SDK. The auth code is shared for all the AWS Scalers, so I guess that it's a potential improvement for all the AWS Scalers and not only for SQS. If any other user needs AwsExternalID for other AWS Scaler, we will need to add the parameter there and pass to the shared auth code.
My suggestion is to remove the parameter from the SQS trigger and moving it directly to the TriggerAuthentication to make in shared for any AWS scaler and also to place it closer to the auth code and not in the SQS code to pass it till auth code. The last but not least, this change ONLY applies if pod identity is used (the assumeRole code is podIdentity code), so I see it configured along podIdentity configuration and not as part of the scaler

[zroubalik]

Awesome improvement! ❤️ As this is part of pod identity (IRSA role assumption), WDYT if we set it as a new parameter in trigger authentication? This would make the new feature available for any AWS Scaler at once.

Could you please elaborate here?

sure, AwsExternalID is part of the auth SDK and not from SQS SDK. The OP has added the parameter to the SQS trigger but it's passed directly to the auth SDK. The auth code is shared for all the AWS Scalers, so I guess that it's a potential improvement for all the AWS Scalers and not only for SQS. If any other user needs AwsExternalID for other AWS Scaler, we will need to add the parameter there and pass to the shared auth code. My suggestion is to remove the parameter from the SQS trigger and moving it directly to the TriggerAuthentication to make in shared for any AWS scaler and also to place it closer to the auth code and not in the SQS code to pass it till auth code. The last but not least, this change ONLY applies if pod identity is used (the assumeRole code is podIdentity code), so I see it configured along podIdentity configuration and not as part of the scaler

Thanks a lot, this make sense!

Fully agree, let's proceed this direction, @tangobango5 FYI