feat(iam): custom role support for OpenIdConnectProvider

[joris-de]

Issue # (if applicable)

None

Reason for this change

OpenIdConnectProvider creates a custom resource, which includes a lambda function. Currently, users cannot provide their own IAM role for this lambda function, it is auto generated. This limits users who need to use pre-existing roles due to organizational policies or specific permission requirements.
Description of changes

Added an optional role property to OpenIdConnectProviderProps that allows users to provide their own IAM role for the custom resource's lambda function. When a custom role is provided:

The custom resource provider uses the provided role instead of creating a new one
Users are responsible for ensuring the role has the required IAM permissions
The addToRolePolicy method throws an error if called when using a custom role

I have tried to automatically add the required IAM permissions to the custom role, but converting the JSON policy statements using PolicyStatement.fromJson() was not possible because it created a circular dependency. I did not find a good way to implement this functionality. Please let me know if you know how to do this.
Describe any new or updated permissions being added

No new permissions are added by this change. When users provide a custom role, they must manually add the required IAM permissions:

'iam:CreateOpenIDConnectProvider'
'iam:DeleteOpenIDConnectProvider'
'iam:UpdateOpenIDConnectProviderThumbprint'
'iam:AddClientIDToOpenIDConnectProvider'
'iam:RemoveClientIDFromOpenIDConnectProvider'

Description of how you validated changes

I added unit tests for the OpenIdConnectProvider and CustomResourceProvider to verify:

Custom roles are properly used when provided
No automatic IAM role is created when a custom role is provided
The lambda function references the custom role ARN
addToRolePolicy throws an error when using custom roles
Existing functionality remains unchanged when no custom role is provided

I also added an integration test where the OpenIDConnectProvider is created with a custom role.

Checklist

• My code adheres to the CONTRIBUTING GUIDE and DESIGN GUIDELINES

---

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 fails with the following errors:

❌ Features must contain a change to an integration test file and the resulting snapshot.
❌ Pull requests from `main` branch of a fork cannot be accepted. Please reopen this contribution from another branch on your fork. For more information, see https://github.com/aws/aws-cdk/blob/main/CONTRIBUTING.md#step-4-pull-request.

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.

[aws-cdk-automation]

Your pull request must be based off of a branch in a personal account (not an organization owned account, and not the main branch). You must also have the setting enabled that allows the CDK team to push changes to your branch (this setting is enabled by default for personal accounts, and cannot be enabled for organization owned accounts). The reason for this is that our automation needs to synchronize your branch with our main after it has been approved, and we cannot do that if we cannot push to your branch.

[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.

[aws-cdk-automation]

Your pull request must be based off of a branch in a personal account (not an organization owned account, and not the main branch). You must also have the setting enabled that allows the CDK team to push changes to your branch (this setting is enabled by default for personal accounts, and cannot be enabled for organization owned accounts). The reason for this is that our automation needs to synchronize your branch with our main after it has been approved, and we cannot do that if we cannot push to your branch.

[aws-cdk-automation]

Your pull request must be based off of a branch in a personal account (not an organization owned account, and not the main branch). You must also have the setting enabled that allows the CDK team to push changes to your branch (this setting is enabled by default for personal accounts, and cannot be enabled for organization owned accounts). The reason for this is that our automation needs to synchronize your branch with our main after it has been approved, and we cannot do that if we cannot push to your branch.

[aws-cdk-automation]

Your pull request must be based off of a branch in a personal account (not an organization owned account, and not the main branch). You must also have the setting enabled that allows the CDK team to push changes to your branch (this setting is enabled by default for personal accounts, and cannot be enabled for organization owned accounts). The reason for this is that our automation needs to synchronize your branch with our main after it has been approved, and we cannot do that if we cannot push to your branch.

[aws-cdk-automation]

Your pull request must be based off of a branch in a personal account (not an organization owned account, and not the main branch). You must also have the setting enabled that allows the CDK team to push changes to your branch (this setting is enabled by default for personal accounts, and cannot be enabled for organization owned accounts). The reason for this is that our automation needs to synchronize your branch with our main after it has been approved, and we cannot do that if we cannot push to your branch.

[aws-cdk-automation]

Your pull request must be based off of a branch in a personal account (not an organization owned account, and not the main branch). You must also have the setting enabled that allows the CDK team to push changes to your branch (this setting is enabled by default for personal accounts, and cannot be enabled for organization owned accounts). The reason for this is that our automation needs to synchronize your branch with our main after it has been approved, and we cannot do that if we cannot push to your branch.