RCP approach doesn't allow EKS IRSA OIDC IdPs

[eddydee123]

The IRSA feature in EKS IAM roles for service accounts - Amazon EKS requires creating an OIDC IdP in the cluster. Each such OIDC IdP has a unique identifier, which cannot be known in advance, although it does have a known prefix.

The approach to limiting OIDC IdPs in https://github.com/aws-samples/resource-control-policy-examples/tree/main/Limit-access-to-trusted-OIDC-identity-providers uses restrictions on the iss: sub or aud: claims in the JWT, which requires the RCP to specify exactly the full IdP identifier. Since this is a key and not a value, it cannot be wildcarded.

For example:

        {
            "Sid": "EnforceTrustedOIDCProviders",
            "Effect": "Deny",
            "Principal": "*",
            "Action": "sts:AssumeRoleWithWebIdentity",
            "Resource": "*",
            "Condition": {
                "Null": {
                    "<OIDC_provider_name_1>:sub": "true",
                    "<OIDC_provider_name_2>:sub": "true"
                }
            }
        },

<OIDC_provider_name_1> in the case of an EKS IRSA is something like oidc.eks.region-code.amazonaws.com/id/EXAMPLED539D4633E53DE1B71EXAMPLE (see Assign IAM roles to Kubernetes service accounts - Amazon EKS)

Every EKS cluster in the entire Organization will have its own OIDC IdP identifier. Again, since this identifier is part of the Condition key, we cannot write something like:
"oidc.eks.region-code.amazonaws.com/id/*:sub": "true"

In an Organization which wants to use EKS IRSA, I don't see how the RCP approach to limiting OIDC IdPs can work at all. We would have to modify the RCP to add the IdP of every EKS cluster that is created, and remove the ones of clusters that get destroyed.

Instead, we should use a SCP which limits iam:CreateOpenIDConnectProvider to a Resource list which includes "oidc.eks.region-code.amazonaws.com/id/*" as well as other whitelisted OIDC IdPs.

[liwadman]

An alternative to consider for IRSA with an RCP would be the federated provider condition key.

aws:FederatedProvider can be used with String Operators with the sts:AssumeRoleWithWebIdentity api operations.

The value of aws:FederatedProvider will be the ARN of the IDP. So you can use wildcards to construct something that allows IRSA, but the problem would be differentiating your EKS clusters with IRSA from other EKS clusters with IRSA, unless you're allow listing by specific AWS accounts with aws:FederatedProvider.

However, what is prefered now by EKS is EKS pod identities to give AWS creds to your EKS workloads, which would not require this type of policy allow-listing for specific OIDC providers.

[eddydee123]

@liwadman from my reading of https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-federatedprovider and https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_principal.html#principal-role-session, and experimenting in Policy Simulator, aws:FederatedProvider is set only after the STS AssumeRoleWithWebIdentity operation completes. Can you use it as a Condition key for the sts:AssumeRoleWithWebIdentity Action itself?

I agree that EKS Pod Identity is easier to manage than IRSA, but at least in my Organization I still need to allow IRSA.

[liwadman]

it's available in both the role session, and in the role trust policy before. This is due to updated in the docs and I have a ticket open for it I will check up on.

You can test this fine-grained in a role trust policy before testing with an RCP to test this.

[liwadman]

Here is an example RCP you could use. You could wildcard and to allow IRSA from any region or account specifically.

Please test in a safe environment before rolling.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Deny",
      "Principal": "*",
      "Action": "sts:AssumeRoleWithWebIdentity",
      "Resource": "*",
      "Condition": {
        "StringNotLike": {
          "aws:federatedProvider": [
            "arn:aws:iam::<account>:oidc-provider/oidc.eks.<region>.amazonaws.com/id/*"
          ]
        }
      }
    }
  ]
}