fix(custom-resources): IAM policy incorrect for SDKv3 names

[rix0rrr]

In the AwsCustomResource and the Assertions libraries, we advertise accepting all of the following service name formats:

• The SDKv3 service name: api-gateway
• The full SDKv3 package name: @aws-sdk/client-api-gateway
• The SDKv2 constructor name: APIGateway
• The SDKv2 constructor name in all lower case: apigateway

And the following action name formats:

• The API call name: GetRestApi
• The API call name with a lowercase starting letter method name: getRestApi
• The SDKv3 command class name: GetRestApiCommand

However, the code that was taking care of mapping service names into an IAM name was not handling all cases correctly. There was also an issue with some commands that end in the word "Command", like ECS's ExecuteCommand, which according to the rules above should work both written as ExecuteCommand as well as ExecuteCommandCommand: we did not have enough information to know if we saw the string ExecuteCommand, whether we should interpret it as Execute or ExecuteCommand.

Also, we were recommending to use the full SDKv3 package name and class name formats:

{
  service: '@aws-sdk/client-api-gateway',
  action: 'GetRestApiCommand',
}

Which looks ugly (imo) and leaks too many of the underlying implementation details.

This PR changes the following:

• Deprecate the sdk-api-metadata.json we extracted from SDKv2.
• From SDKv3 models, extract a new sdk-v3-metadata.json which contains the following information:
  • IAM prefix for every service
  • A list of APIs that end in the word Command, so we can disambiguate around these.
• From aws-sdk-codemod, extract a mapping from SDKv2 service names to SDKv3 service names (replacing the copy/pasted code we used to have with a build-time extraction).
• Unfortunately, both of these mappings are duplicated: once for the construct library, and once for the handlers. I did not want to go into deduplicating between these for now.
• At runtime, we now map a potential V2 service name to a V3 service name, then look up the V3 metadata to determine the IAM prefix and the normalized action name.
• There was a lot of duplication between the assertions handler and the AwsCustomResource handler (and to a lesser degree, the events.ApiCall handler), around loading SDKs and coercing values. Introduce a new ApiCall class that unifies the behavior between these call sites.
• Change the recommendation in the README from using SDKv3 names to using shorter form names (api-gateway and GetRestApi).
• Add "dynamic reuqire" protection to the esbuild commands for custom resources.

Fixes #27255, closes #27268, closes #27270, closes #27395.

---

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.

[MrArnoldPalmer]

Approved with DNM. I'm onboard with the deprecation of metadata and the change in opinion to not use the v3 specific library service formatting, and of course all the dedupe stuff.

A question around naming/versioning but on second thought I'm less concerned with it but I'll give you a chance to respond in case it does spark something for you or @mrgrain .

[gerardorn]

Not sure if this is will solve the issue but im having the same problem with @aws-sdk/client-network-firewall in go

fwEndpoints := customresources.NewAwsCustomResource(nested, jsii.String("route"), &customresources.AwsCustomResourceProps{
  OnCreate: &customresources.AwsSdkCall{
    Service:            jsii.String("@aws-sdk/client-network-firewall"),
    Action:             jsii.String("DescribeFirewallCommand"),
    PhysicalResourceId: customresources.PhysicalResourceId_Of(jsii.String("route")),
    Parameters: map[string]interface{}{
      "FirewallName": jsii.String(*fw.FirewallName()),
    },
  },
  Policy: customresources.AwsCustomResourcePolicy_FromSdkCalls(&customresources.SdkCallsPolicyOptions{
    Resources: customresources.AwsCustomResourcePolicy_ANY_RESOURCE(),
  }),
})

Error message:
panic: Action '@aws-sdk/client-network-firewall:DescribeFirewallCommand' is invalid. An action string consists of a service namespace, a colon, and the name of an action. Action names can include wildcards.

[rix0rrr]

@gerardorn yes it will. You can unblock yourself by not using the SDKv3 package names, but just using the simple (V2) service and action name (networkfirewall, describeFirewall), or adding the IAM permission explicitly.

[gerardorn]

hey @rix0rrr, thanks for your answer 🙏🏼
Tried using all lower case and didn't work

Received response status [FAILED] from custom resource. Message returned: Client 'networkfirewall' is either deprecated or newly added. Please consider using the v3 package format (@aws-sdk/client-xxx). (RequestId: ab36f12a-7d03-4fce-8237-38b91f7cc5c6)

Had to use this approach

fwEndpoints := customresources.NewAwsCustomResource(nested, jsii.String("route"), &customresources.AwsCustomResourceProps{
  OnCreate: &customresources.AwsSdkCall{
    Service:            jsii.String("NetworkFirewall"),
    Action:             jsii.String("describeFirewall"),
    PhysicalResourceId: customresources.PhysicalResourceId_Of(jsii.String("route")),
    Parameters: map[string]interface{}{
      "FirewallName": jsii.String(*fw.FirewallName()),
    },
  },
  Policy: customresources.AwsCustomResourcePolicy_FromSdkCalls(&customresources.SdkCallsPolicyOptions{
    Resources: customresources.AwsCustomResourcePolicy_ANY_RESOURCE(),
  }),
})

Hope this helps 🙌🏼

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

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

[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: 7f0bea7
• 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).