fix: Wrong STS audience in OIDC provider in China partition

[pkolakow]

Description

Change STS Audience service endpoint to point to the correct partition.

Motivation and Context

When deploying EKS cluster in china partition you have to specify the following variable because the EKS have amazonaws.com not amazonaws.cn dns_suffix:

cluster_iam_role_dns_suffix = "amazonaws.com"

Unfortunatelly, this variable is also used to determine STS Audience in OIDC provider when IRSA is enabled.
The correct STS endpoint in China partion is sts.amazonaws.com.cn not sts.amazonaws.com and should not depend on cluster_iam_role_dns_suffix variable.

Breaking Changes

The OIDC provider will be forcfully replaced but because of the wrong STS audience it wasn't usable anyway.

How Has This Been Tested?

• I have updated at least one of the examples/* to demonstrate and validate my change(s)
• I have tested and validated these changes using one or more of the provided examples/* projects

• I have executed pre-commit run -a on my pull request

[bryantbiggs]

I believe what we have is correct - you can see the history here:

• incorrect eks service principal for AWS China #1904
• fix: Correct DNS suffix for OIDC provider #2026

[pkolakow]

@bryantbiggs I disagree. IMO #2026 introduced a bug. I've got multiple environments in China partition and the correct way is to have the following trust relationship for the cluster IAM role:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "EKSClusterAssumeRole",
            "Effect": "Allow",
            "Principal": {
                "Service": "eks.amazonaws.com"
            },
            "Action": "sts:AssumeRole"
        }
    ]
}

and sts.amazonaws.com.cn in the audience in the OIDC provider.

They cannot have the same DNS suffix.

Thus, it is also required to this annotation to ServiceAccount:

eks.amazonaws.com/audience: "sts.amazonaws.com.cn"

Even if it is possible to use the sts.amazonaws.com audience and specify the corresponding annotation to ServiceAcount, the change introduced in #2026 is backward incompatible and will result in all Pods not being to authenticate to AWS until restarted (also there would be a need to change all ServiceAcount manifests on the cluster).

Maybe it would be reasonable to introduce a separate variable for the default STS audience?

[github-actions]

I'm going to lock this pull request because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. If you have found a problem that seems related to this change, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.