- Original Author(s):: @hassaku63
- Tracking Issue: #512
- API Bar Raiser: -
Allow the OpenIdConnectProvider construct to internally use the native CloudFormation Resource AWS::IAM::OIDCProvider.
This section should contain one or more "artifacts from the future", as if the feature was already released and we are publishing its CHANGELOG, README, CONTRIBUTING.md and optionally a PRESS RELEASE. This is the most important section of your RFC. It's a powerful thought exercise which will challenge you to truly think about this feature from a user's point of view.
- CHANGELOG: Write the changelog entry for this feature in conventional form (e.g.
feat(eks): cluster tags). If this change includes a breaking change, include aBREAKING CHANGEclause with information on how to migrate. If migration is complicated, refer to a fictional GitHub issue and add its contents here.
feat(iam): add the option for OpenIdConnectProvider construct to use CfnOIDCProvider internally
- README: If this is a new feature, write the README section which describes this new feature. It should describe the feature and walk users through usage examples and description of the various options and behavior.
- PRESS RELEASE: If this is a major feature (~6 months of work), write the press release which announces this feature. The press release is a single page that includes 7 paragraphs: (1) summary, (2) problem, (3) solution, (4) leader quote, (5) user experience, (6) customer testimonial and (7) one sentence call to action.
The OpenIdConnectProvider currently relies on CloudFormation custom resource. This proposal is possible to allow it to internally use the native L1 construct CfnOIDCProvider, which corresponds to the AWS::IAM::OIDCProvider in CloudFormation.
With this proposal, users will have the option to define the OIDCProvider resource without the need to create a Lambda Function for custom resources.
Ticking the box below indicates that the public API of this RFC has been
signed-off by the API bar raiser (the api-approved label was applied to the
RFC pull request):
[ ] Signed-off by API Bar Raiser @xxxxx
This section should include answers to questions readers will likely ask about this release. Similar to the "working backwards", this section should be written in a language as if the feature is now released.
The template includes a some common questions, feel free to add any questions that might be relevant to this feature or omit questions that you feel are not applicable.
これまでの CDK ユーザーはどうする必要がある？ 後方互換性はあるのか？ 新しく CDK プロジェクトを開始するユーザーはどうすれば新旧の挙動を使い分ける？
What exactly are we launching? Is this a new feature in an existing module? A new module? A whole framework? A change in the CLI?
新しい feature flag IAM_DISABLE_OIDC_PROVIDER_CUSTOM_RESOURCE をリリースする。
（もしくは肯定形にして IAM_USE_OIDC_PROVIDER_CFN_RESOURCE など）
この値のデフォルト値は false であること（つまり既存のプロジェクトでは変わらず CustomResource を使う）、
今後の推奨は true で、新規プロジェクトを立ち上げた場合は true になることを示す。
また、true を指定した場合は OpenIdConnectProvider リソースは内部的に CfnOidcProvider を使うようになることを示す。
Describe use cases that are addressed by this feature.
今後 OpenIdConnectProvider リソースを利用するすべてのユーザーに対して利用を推奨する。
本来不要であるカスタムリソースの作成を回避できるため、成果物がよりシンプルになる。
Set feature flag @aws-cdk/aws-iam:iamUseOidcProviderCfnResource true.
show an exmaple below (define in cdk.json)
{
"context": {
"@aws-cdk/aws-iam:iamUseOidcProviderCfnResource": true
}
}A new feature flag iamUseOidcProviderCfnResource will be used to determine the (OpenIdConnectProvider リソースの構築に cfn OIDCProvider を使うかどうか、的な英文)
Use OpenIdConnectProvider class.
const provider = new iam.OpenIdConnectProvider(this, 'MyProvider', {
url: 'https://openid/connect',
clientIds: [ 'myclient1', 'myclient2' ],
});Ideally, one should avoid using custom resources to create resources that can be defined as native CloudFormation resources.
Use CfnOidcProvider L1 construct.
（または、明示的に Feature flag を無効化するように書く）
Briefly describe the high-level design approach for implementing this feature.
As appropriate, you can add an appendix with a more detailed design document.
This is a good place to reference a prototype or proof of concept, which is highly recommended for most RFCs.
既存の OpenIdConnectProvider のインタフェースを維持しながら、Feature flag が有効な場合のみ内部的に CfnOidcProvider を使うようにする。
If the answer is no. Otherwise:
Describe what ways did you consider to deliver this without breaking users?
Make sure to include a
BREAKING CHANGEclause under the CHANGELOG section with a description of the breaking changes and the migration path.
No.
Briefly describe alternative approaches that you considered. If there are hairy details, include them in an appendix.
なし
Describe any problems/risks that can be introduced if we implement this RFC.
Describe your plan on how to deliver this feature from prototyping to GA. Especially think about how to "bake" it in the open and get constant feedback from users before you stabilize the APIs.
If you have a project board with your implementation plan, this is a good place to link to it.
Describe any major open issues that this RFC did not take into account. Once the RFC is approved, create GitHub issues for these issues and update this RFC of the project board with these issue IDs.
Feel free to add any number of appendices as you see fit. Appendices are expected to allow readers to dive deeper to certain sections if they like. For example, you can include an appendix which describes the detailed design of an algorithm and reference it from the FAQ.