feat(iam): move OpenIdConnectProvider to native Cfn resource

[CaerusKaru]

An L1 construct is now available for OpenID IAM identity providers.
This moves the previous L2 construct to use the L1 instead of the
existing custom resource, relieving the user of both the resource
overhead and the permissioning implications of the attached role.

BREAKING CHANGE: OpenIdConnectProvider::fromOpenIdConnectProviderArn -> OpenIdConnectProvider::fromOidcProviderArn

• iam: OpenIdConnectProvider.openIdConnectProviderArn -> OpenIdConnectProvider::oidcProviderArn
• iam: OpenIdConnectProviderProps.thumbprints now requires at least one entry
• iam: The custom resource behind OpenIdConnectProvider has been removed and is no longer available

---

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

[gitpod-io]

[CaerusKaru]

Yes, I know this is a breaking change for IAM, and yes I know IAM is stable. But custom resource to stable CloudFormation resource seems like the right move to me in general. Happy to target this to a new branch or anything else.

[aws-cdk-automation]

AWS CodeBuild CI Report

• CodeBuild project: AutoBuildProject89A8053A-LhjRyN9kxr8o
• Commit ID: dfd0d34
• Result: FAILED
• Build Logs (available for 30 days)

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

[rix0rrr]

I don't disagree that this is better, but we have to think about the implications for already-deployed stacks. Can I make the following suggestion:

• Rename current OpenIdConnectProvider to OpenIdConnectProviderCustomResource (or OpenIdConnectProviderLegacy)
• Add the new provider as OpenIdConnectProviderNative

And then feature-flag the implementation of OpenIdConnectProvider to look like this:

class OpenIdConnectProvider extends Resource {
  constructor(...props) {
    
    if (FeatureFlags.of(this).isEnabled(IAM_NATIVE_OPENID_CONNECT_PROVIDER)) {
      new OpenIdConnectProviderNative(this, 'Default', props);
    } else {
      new OpenIdConnectCustomResource(this, 'Default', props);
    }
  }
}

And then document the shit out of it... @eladb what do you think?

BTW this needs to be a flag that does NOT go away in V2, because we want people to be able to upgrade to V2 without having to force a recreation of this resource. @nija-at as the person with the most state on Feature Flags, what would that look like?

[nija-at]

BTW this needs to be a flag that does NOT go away in V2, because we want people to be able to upgrade to V2 without having to force a recreation of this resource. @nija-at as the person with the most state on Feature Flags, what would that look like?

Just adding the feature flag and not doing anything extra for v2 will just work here.
If we need the default for the flag to be changed to 'true' (not the one in cdk.json init template), then we change that in the v2 branch -

aws-cdk/packages/@aws-cdk/cx-api/lib/features.ts

Line 214 in 2f92e63

const FUTURE_FLAGS_DEFAULTS: { [key: string]: boolean } = {

[TheRealAmazonKendra]

This PR has been deemed to be abandoned, and will be closed. Please create a new PR for these changes if you think this decision has been made in error.