feat(iam): introduce OidcProviderNative construct utilizing the native CloudFormation resource

[WarFox]

IAM is stable in CDK, so we should not introduce breaking changes. This PR introduces a new version of OIDC provider without introducing breaking changes.

Older iam.OpenIdConnectProvider, which uses custom resources with lambda, is marked as deprecated.

The newly introduced OidcProviderNative uses the native CloudFormation resource AWS::IAM::OIDCProvider

ThumbprintList

ThumbprintList must not be empty when using AWS::IAM::OIDCProvider
https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_create_oidc_verify-thumbprint.html
https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-iam-oidcprovider.html
https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreateOpenIDConnectProvider.html

Closes #21197

---

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license

[aws-cdk-automation]

The pull request linter has failed. See the aws-cdk-automation comment below for failure reasons. If you believe this pull request should receive an exemption, please comment and provide a justification.

A comment requesting an exemption should contain the text Exemption Request. Additionally, if clarification is needed add Clarification Request to a comment.

[WarFox]

The integration test is failing with the following error now

Thumbprint list must contain at least one entry

 ❌ Deployment failed: Error: The stack named oidc-provider2-integ-test failed creation, it may need to be manually deleted from the AWS console: ROLLBACK_COMPLETE: Resource handler returned message: "Thumbprint list must contain at least one entry. (Service: Iam, Status Code: 400, Request ID: 117aab55-6bd3-4521-b478-c065f144c48f)" (RequestToken: 618dd5f3-0cc7-a4f0-d899-f2d793dc5f4b, HandlerErrorCode: InvalidRequest), Resource handler returned message: "Thumbprint list must contain at least one entry. (Service: Iam, Status Code: 400, Request ID: b9dbef07-5151-480e-8e74-8e15fe414db6)" (RequestToken: 35d9515c-d891-edd8-123d-73a69ffbd4af, HandlerErrorCode: InvalidRequest)

✅ Updated pull request passes all PRLinter validations. Dismissing previous PRLinter review.

[WarFox]

Clarification Request

What do you think of renaming iam.OpenIdConnectProvider2 to iam.OidcProvider?

I chose OpenIdConnectProvider2, just to make sure not to introduce a breaking change to OpenIdConnectProvider that uses a custom resource and follows the same naming pattern.

OidcProvider will be better suited to match with the AWS::IAM::OIDCProvider resource in CloudFormation.

I suggest the following name changes:

IOpenIdConnectProvider2 - IOidcProvider
OpenIdConnectProvider2Props  -> OidcProviderProps
OpenIdConnectProvider2 -> OidcProvider

and filename change to

aws-iam/lib/oidc-provider2.ts -> aws-iam/lib/oidc-provider-cfn.ts

[paulhcsun]

The implementation for the original OpenIdConnectProvider passed in a CodeHash from the provider so that CFN invokes the UPDATE handler when there are code change but the properties of the resource haven't changed.

Is this problem is fixed by using CfnOIDCProvider?

For more context: https://github.com/aws/aws-cdk/pull/22802/files#r1018838729

[WarFox]

thank you for the comment. I shall look into this

[paulhcsun]

Hi @WarFox, I agree that using the name OidcProvider makes sense because it better aligns with the AWS::IAM::OIDCProvider that is being used but I feel like it may create too much confusion with the old resource, at least not without a lot more documentation.

After discussing with the team I believe the best option here is to use a feature flag and add changes to the existing OpenIdConnectProvider as suggested here: #16014 (comment) with the following caveats:

• The feature flag should toggle between the two constructs, OpenIdConnectProvider, and OpenIdConnectProvider2 in the constructor of OpenidConnectProvider.
• Rename OpenIdConnectProvider2 to OpenIdConnectProviderNative. But don't export it, only allow it to be used via OpenIdConnectProvider + feature flag

[WarFox]

thanks for pointing out to #16014 (comment) @paulhcsun. I shall look into how a feature flag is helpful for this, it is interesting.

What do you think of naming it OidcProvider instead of OpenIdConnectProviderNative? When I come from using a CloudFormation resource to a CDK resource, I usually expect name parity. It will also be helpful from a search point of view i.e. someone searching for OidcProvider will find the correct resource too.

Just to confirm, is the consensus in your team NOT to deprecate OpenIdConnectProvider?

[paulhcsun]

Hey @WarFox,

While I agree that it would be good to have name parity with OidcProvider, I don't think the name is clear how it's different from OpenIdConnectProvider. Having Native in the name makes it explicit what the difference is. Or at the very least something like OIDCProviderNative if we want to have the resource show up when users search for "oidc".

My opinion is to go with OpenIdConnectProviderNative as it's meant to replace OpenIdConnectProvider so users switching over would expect to search for the same name when looking for this resource.

As for deprecation, we would NOT deprecate OpenIdConnectProvider as it would still be used to return the new OpenIdConnectProviderNative through its constructor when the feature flag is enabled. However we should still document somewhere that the old version which uses custom resources is deprecated. One place could be here, and then explain the new feature flag and how it would return the new version of OpenIdConnectProviderNative.

Pull request has been modified.

[paulhcsun]

I don't think this property should be required. From the CFN docs it seems like it's optional and that there is a default certificate used if none is provided:

This property is optional. If it is not included, IAM will retrieve and use the top intermediate certificate authority (CA) thumbprint of the OpenID Connect identity provider server certificate.

I've checked with the service team and they said that if customer does not provide thumbprint, IAM will query Discovery Service to see if the Url provided is a valid Url, and based on the response IAM will either reject or accept the Url that customer provided.

I think we should make this optional and document this behaviour in the docstring and follow the service team's behaviour where possible.

[WarFox]

have made it optional

[WarFox]

thanks for pushing this and updating the snapshots @paulhcsun

It wasn't working for me, probably because of my broken local setup

[paulhcsun]

All good! Thanks for adding the integration test assertions :) I totally missed it before when I was just checking the commit messages. Once the build passes I'll be happy to approve this and get this finally merged in. Thank you so much for your patience and work put into this contribution!

As a note for any local build failures or general issues with unknown causes, I usually just run git clean -fqdx . and then rebuild as if I cloned a new CDK repo and that usually fixes things up!

[mergify]

Thank you for contributing! Your pull request will be updated from main and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork).

[aws-cdk-automation]

AWS CodeBuild CI Report

• CodeBuild project: AutoBuildv2Project1C6BFA3F-wQm2hXv2jqQv
• Commit ID: b781801
• Result: SUCCEEDED
• Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

[mergify]

Thank you for contributing! Your pull request will be updated from main and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork).

[github-actions]

Comments on closed issues and PRs are hard for our team to see.
If you need help, please open a new issue that references this one.