PEERDB_REQUEST_SIGNING_KEYS: json map of allowed key IDs, map of keyID to keyValue, in case of KMS, keyId and keyValue will be same, will allow for key rotation as well as using different keys for different entities.
Request will only be accepted if:
x-peerdb-request-signing-key-id is present in PEERDB_REQUEST_SIGNING_KEYS
Current plan is to only have this on certain GRPC methods and implement for AWS Asymmetric keys. This will NOT work on HTTP requests, a separate interceptor can be added for HTTP request body with common methods.
Assuming the following metadata-keys/headers are available on request:
x-peerdb-request-signature
:v1,<Base64EncodedSignature>
x-peerdb-request-type
:digest
/raw
x-peerdb-request-timestamp
: (optional for now), the time when request was created, will have tolerance check to prevent replay attacksx-peerdb-request-signing-key-id
:keyID
for signingx-peerdb-request-signing-alg
: algorithm used for signingThe following env vars are used:
PEERDB_REQUEST_SIGNING_VERIFICATION_ENABLED
:true
/false
PEERDB_REQUEST_SIGNING_KEY_TYPE
:AWS_KMS_SIGN
for nowPEERDB_REQUEST_SIGNING_TIMESTAMP_TOLERANCE_SECONDS
PEERDB_REQUEST_SIGNING_KEYS
: json map of allowed key IDs, map ofkeyID
tokeyValue
, in case of KMS, keyId and keyValue will be same, will allow for key rotation as well as using different keys for different entities.Request will only be accepted if:
x-peerdb-request-signing-key-id
is present inPEERDB_REQUEST_SIGNING_KEYS
Current plan is to only have this on certain GRPC methods and implement for AWS Asymmetric keys. This will NOT work on HTTP requests, a separate interceptor can be added for HTTP request body with common methods.