### Is there an existing issue for this?

- [X] I have searched the existing issues

### Current Behavior

When attempting to sign some document using Localstack KMS inside a lambda container (also running on localstack), the localstack KMS listener returns some unknown error.

The KMS key and lambda containers have been created from the same CDK app deploy, and I can see all the resources in the localstack web console.

The test application I'm using to prove this behaviour is available here:
https://github.com/LukaHedt/localstack_kms_test

Instructions to run are in the main Readme, and the `/localstack/Readme.md` file.

`aws-sdk` returns an unknown error, and the localstack docker logs that I receive are available here:
https://pastebin.com/58Z3fXi3

Have done an amount of testing and can confidently claim the following:
- Have tested on multiple machines with the same outcome
- Doesn’t make a difference if I specify an ARN or a KeyID in the signing request
- Downgrading localstack versions either didn’t make a difference, or I couldn’t actually deploy a localstack container with version 0.12.20 or lower.

### Expected Behavior

KMS Sign should return a signature for the given payload.

### How are you starting LocalStack?

With a docker-compose file

### Steps To Reproduce

Test application demonstrating the current behaviour is available here:

https://github.com/LukaHedt/localstack_kms_test

Full instructions to run are in the `/localstack/Readme.md` file.


### Environment

```markdown
- OS: MacOS Monteray 12.3
- LocalStack: 0.14.0
```


### Anything else?

_No response_
Creates the right serializer for the given service model.
    **Experimental:** The serializers in this module are still experimental.
    When implementing services with these serializers, some edge cases might
    not work out-of-the-box.
    :param service: to create the serializer for
    :return: ResponseSerializer which can handle the protocol of the service
    """
    # Unfortunately, some services show subtle differences in their serialized responses, even though their
    # specification states they implement the same protocol.
    # Since some clients might be rs, we need to mimic the serialization of the
    # specific services as close as possible.
    # Therefore, the service-specific serializer implementations (basically the implicit / informally more specific
    # protocol implementation) has precedence over the more general protocol-specific serializers.
    service_specific_serializers = {
        "sqs": SqsResponseSerializer,
    }
    protocol_specific_serializers = {
        "query": QueryResponseSerializer,
        "json": JSONResponseSerializer,
        "rest-json": RestJSONResponseSerializer,
        "rest-xml": RestXMLResponseSerializer,
        "ec2": EC2ResponseSerializer,
    }
    # Try to select a service-specific serializer implementation
    if service.service_name in service_specific_serializers:
        return service_specific_serializers[service.service_name]()
    else:
        # Otherwise, pick the protocol-specific serializer for the protocol of the service
        return protocol_specific_serializers[service.protocol]()