node: add amazon kms and benchmark signers #4168
Open
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Amazon KMS Guardian Signer
This PR adds an Amazon AWS KMS Guardian signer, allowing observations to be signed using KMS! The new signer can be used by specifying the ARN of the KMS key to use, through the
--guardianSignerUri
commandline argument, as follows:--guardianSignerUri=amazonkms://<ARN>
NOTE For the best possible performance, it is recommended that the Guardian be run from an EC2 instance that is in the same region as the KMS key.
The KMS key's spec should be
ECC_SECG_P256K1
, and should be enabled for signing. In order for the Guardian to authenticate against the KMS service, one of two options are available:~/.aws/credentials
file. (example here).Benchmark Signer
The PR also includes a benchmark signer, which wraps any other signer, logging signing and verification latency to prometheus histograms. External signing services might at times introduce unwanted latency, and if an event occurs where observation processing is particularly slow, the histograms would provide insight into whether or not the signing service is to blame.
NOTE
This is a redo of a previous pull request, which Pires spent time looking at. Below are key points following that review that informs the current state of the code:
Context
s should be supplied to signing, verification and public key retrieval, as these functions potentially interact with 3rd party services that could timeout or block indefinitely.GuardianSigner
constructor (NewGuardianSignerFromUri
) accepts aContext
, as the new signer might need to interact with the 3rd party service to validate configurations (such as theAmazonKms
signer). A different approach could be to have the constructor define its own context, to avoid the necessity of passing a context to it.