According to https://github.com/aws/aws-sdk-java-v2/blob/master/docs/LaunchChangelog.md#11-client-creation-defaults, the V2 SDK no longer supports the com.amazonaws.sdk.disableCertChecking system property usage.
This parameter was a key item when interacting with Localstack, which has served as the primary local mock for Kinesis in the OSS community. This is because Localstack randomly generates self-signed certificates. It is not possible to interact with those certificates without disabling the validation of them.
It is possible to continue to leverage Localstack with the KCL, but the setup requires a much larger investment from a developer; i.e. creating self-signed certificates, trust stores, etc. for use in their app.
Please bring this control back. The developer community would greatly appreciate it.
Using com.amazonaws.sdk.disableCertChecking as a system property disables SSL certificate validation.
Using com.amazonaws.sdk.disableCertChecking is not supported for any purpose.
Re-introduce com.amazonaws.sdk.disableCertChecking as a control for validating certificates.
version: '2.2'
services:
localstack-base:
image: "${DOCKER_REPOSITORY}/localstack/localstack:0.9.1"
environment:
- "SERVICES=kinesis,cloudwatch,dynamodb"
- "USE_SSL=true"
- "DEFAULT_REGION=${LOCALSTACK_DEFAULT_REGION:-us-east-1}"
- "KINESIS_PORT_EXTERNAL=${LOCALSTACK_KINESIS_PORT_EXTERNAL:-4568}"
- "CLOUDWATCH_PORT_EXTERNAL=${LOCALSTACK_CLOUDWATCH_PORT_EXTERNAL:-4582}"
- "DYNAMODB_PORT_EXTERNAL=${LOCALSTACK_CLOUDWATCH_PORT_EXTERNAL:-4569}"
com.amazonaws.sdk.disableCertChecking system property in your applicationKinesisAsyncClient against a localstack endpoint (typically https://localhost:4568)I am trying to develop local integration tests for my application's kinesis producers and consumers.
2.5.10This is an intentional decision to not allow disabling certs. We have a configuration option though that you can specify while creating the client. Is this enough for your use case?
I would suggest being careful when using that option (only use for local testing) as it can lead to security issues.
It might! I'll give it a whirl and report back.
That does seem to work!
The intentional decision to not support that option seems odd when you support a configuration option that works just as well. Why not just allow for this configuration option to _also_ be configured via the property? Then users would not have to adapt their code to work locally.
We only put the configuration option for internal testing and generally discourage customers from using it. Allowing it through system property might cause wider impact if someone enables the option for testing but accidentally run it for production. We currently don't have any plans to expose it as system property/env variable. If there is sufficient interest, we can revisit the decision.
I don't believe this will really prevent people from messing up.
If I notice this flag is enabled in prod, with this SDK, I would need to go and figure out how to restructure my code to allow the flag in test and not in prod (making sure it gets applied or not applied to all SDK clients). With a flag, I can simply remove the flag from my runner.
So I would prefer to have the property flag back.
Most helpful comment
I don't believe this will really prevent people from messing up.
If I notice this flag is enabled in prod, with this SDK, I would need to go and figure out how to restructure my code to allow the flag in test and not in prod (making sure it gets applied or not applied to all SDK clients). With a flag, I can simply remove the flag from my runner.
So I would prefer to have the property flag back.