feat(relay): add mechanism to only allow events from trusted relays #4772
Conversation
There was a problem hiding this comment.
Good stuff on the integration test doc strings, we should do that more often.
I spent a bit more time thinking about internal Relays. Right now we would be signing requests but not verifying the signature (as the Relay is internal).
I think we have 2 ways forward here, we can also verify the new signature against the internal keys, or not sign requests when we know the upstream is also internal, which we might be able to auto detect or just make it configurable if outbound envelope requests should be signed.
I am not opposed to just dealing with this in a follow-up, but we should have an eye on the CPU utilization when rolling this out.
I will create a follow-up ticket for this |
This PR introduces a new discard reason that will be shown in the UI: `Invalid Signature`. ref RELAY-17 See: getsentry/relay#4772
This PR introduces a new discard reason that will be shown in the UI: `Invalid Signature`. ref RELAY-17 See: getsentry/relay#4772
This PR adds a signature to requests between relays which is used to verify if the request comes from a trusted relay.
It leverages the signature mechanism used by
relay-authwhich already includes a timestamp which can be checked for amax_age. The signature itself does not contain any data since we are not interested in data integrity and we just want to see if we can successfully verify the signature by any of the public keys that are added by the user.Envelopes coming from internal relays are not checked because they are already in our infrastructure and are considered trusted.
The
max_agefor envelopes from external relays is set to 5 Minutes currently.ref RELAY-17