Skip to content

Make it harder for users to accidentally launch new (Canton) nodes via faulty config overrides #2644

@martinflorian-da

Description

@martinflorian-da

A validator operator (using Docker compose deployment route) recently encountered a very hard-to-debug issue that ultimately turned out to be due to the following misconfiguration:

ADDITIONAL_CONFIG_SPLICE_PARTICIPANT_CRYPTO_PROVIDER_KMS=
            canton.participants.participant1.crypto.provider = kms
            canton.participants.participant1.crypto.kms {
                type = aws
                region = ${AWS_REGION}
                multi-region-key = false # optional, default is false
                audit-logging = true # optional, default is false
            }

Hard to see, but the issue is that they did canton.participants.participant1 instead of canton.participants.participant. participant is what the image deploys by default; somehow Canton happily also accepted participant1 here instead of failing, and this resulted in it creating a second participant inside the same container... (They used participant1 because they were following some guide on the Canton docs.)

I'm not sure how to best resolve this and also not sure which other images are affected. Part of this issue is to figure these things out.

I also don't know how often a sneaky misconfiguration like this might happen. I suggest prioritizing this issue only if something related happens again.

Metadata

Metadata

Labels

No labels
No labels

Type

No type

Projects

No projects

Relationships

None yet

Development

No branches or pull requests

Issue actions