Cloudformation-coverage-roadmap: AWS::EKS::Cluster - Add return value for OIDC provider URL

[philipakash]

1. Title

AWS::EKS::Cluster : Add Return Value for OpenID Connect provider URL

2. Scope of request

With the launch of EKS Service Account IAM Role mapping , it would be great to add a new return value for the OpenID Connect provider URL while creating the AWS EKS cluster so that the value could be easily used in Trust Relationship under an IAM role.

As roadmap already covers https://github.com/aws-cloudformation/aws-cloudformation-coverage-roadmap/issues/53 it will be great to have return value added to the AWS::EKS::Cluster CF resource.

3. Expected behavior

While CREATE or UPDATE of the CF Resource AWS::EKS::Cluster should add a return value OidcUrl eg: !GetAtt MyCluster.OidcUrl

4. Suggest specific test cases

5. Helpful Links to speed up research and evaluation

https://github.com/aws-cloudformation/aws-cloudformation-coverage-roadmap/issues/53
https://docs.aws.amazon.com/eks/latest/userguide/enable-iam-roles-for-service-accounts.html
https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-eks-cluster.html#aws-resource-eks-cluster-return-values

6. Category

Compute ( EKS )

7. Any additional context

This will be helpful with the Onboarding of new application pods to EKS cluster with Container IAM permissions.

[fimbulvetr]

I think you'll also need this feature as well, in order to actually use the URL in the conditions of the IAM role: https://github.com/aws-cloudformation/aws-cloudformation-coverage-roadmap/issues/198

Also worth noting we that URL itself is not useful unless we can strip the 'https://', which can be done with an unsightly implementation of fn::split & fn::select.

[mak-1-sim]

"Must be" feature that will help create and configure infrastructure without using "bells, whistles, and crutches".

[hlascelles]

I've written up how to get an OIDC provider out of an EKS cluster (with the https:// pre-stripped for use in pods) using a pure* CloudFormation template here: https://bambooengineering.io/configuring-eks-for-iam-oidc-using-cloudformation/ . Hopefully it will tide you over until the official AWS support comes out.

* inlined lambdas are needed. But it is still all yaml.

[sander-su]

Would also be nice to have the OidcProviderID, with which the url can be build.

The following workaround can be used to return it without lambda's.

```
Outputs:
OidcProviderID:
Description: The OpenID Connect provider ID
Value: !Select [0, !Split [".", !Select [1, !Split ["//", !GetAtt EKSCluster.Endpoint]]]]

[rohits-spec]

Launched as part of 4/29 release. https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-eks-cluster.html

[colinbjohnson]

An example of how to use the OpenIdConnectIssuerUrl attribute when creating an AWS IAM Role resource:

EKSClusterCloudWatchIAMRole:
  Type: AWS::IAM::Role
  Properties:
    AssumeRolePolicyDocument:
      Fn::Sub:
        - '{
            "Version": "2012-10-17",
            "Statement": [
              {
                "Action": "sts:AssumeRoleWithWebIdentity",
                "Condition": {
                  "StringEquals": {
                    "${OpenIdConnectIssuer}:aud": "sts.amazonaws.com",
                    "${OpenIdConnectIssuer}:sub": "system:serviceaccount:amazon-cloudwatch:cwagent-prometheus"
                  }
                },
                "Effect": "Allow",
                "Principal": {
                  "Federated": "arn:aws:iam::${AWS::AccountId}:oidc-provider/${OpenIdConnectIssuer}"
                }
              }
            ]
          }'
        - { OpenIdConnectIssuer: !Select [1, !Split ["//", !GetAtt EKSCluster.OpenIdConnectIssuerUrl]] }
    ManagedPolicyArns:
      - arn:aws:iam::aws:policy/CloudWatchAgentServerPolicy
    RoleName: EKSClusterCloudWatchIAMRole

[colinbjohnson]

I think you'll also need this feature as well, in order to actually use the URL in the conditions of the IAM role: #198

Also worth noting we that URL itself is not useful unless we can strip the 'https://', which can be done with an unsightly implementation of fn::split & fn::select.

I was able to work around the inability to use intrinsic functions in left-hand values by defining the AssumeRolePolicyDocument (which is, in my understanding, where the keys need to be dynamically created) by defining the AssumeRolePolicyDocument as a multiline string.