Beholder CSA Authentication #877
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
4of9
force-pushed
the
INFOPLAT-1071-beholder-csa-signer-auth_2
branch
from
f6a504c to
e6e43bc
Compare
4of9
force-pushed
the
INFOPLAT-1071-beholder-csa-signer-auth_2
branch
from
65a2d33 to
67152b5
Compare
pavel-raykov
reviewed
Nov 7, 2024
pavel-raykov
previously approved these changes
Nov 7, 2024
pkg/beholder/auth.go
Outdated
| // where the byte value of <public_key_hex> is what's being signed | ||
| func BuildAuthHeaders(signer func([]byte) []byte, pubKey []byte) map[string]string { | ||
| messageBytes := pubKey | ||
| signature := signer(messageBytes) |
There was a problem hiding this comment.
/nit but do we need to support multiple signing functions? Can we lock the functionality down in this module to save consumers from possibly duplicating/using invalid signing methods?
There was a problem hiding this comment.
good point, I think realistically we'll just be supporting ed25519 unless something takes the place of CSA keys
jmank88
reviewed
Nov 7, 2024
jmank88
approved these changes
Nov 7, 2024
pkcll
approved these changes
Nov 7, 2024
pkcll
approved these changes
Nov 7, 2024
pavel-raykov
approved these changes
Nov 8, 2024
pavel-raykov
approved these changes
Nov 8, 2024
…r-csa-signer-auth_2
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
What
Notes
Design Context
Challenges
Two main challenges were in mind when arriving at an authentication mechanism for Beholder:
Why no mTLS
mTLS can secure the connection between the sidecar collector and the gateway, while also providing identity and authentication
This was decided against as we wouldn't be able to lean on an existing system. While CSA keys do power mTLS today in WSRPC, they're being used in a non-standard way with the certificates being generated in-memory. To use these certificates in the sidecar collector would require writing them to disk (a new security consideration).
Furthermore, mTLS is one of the reasons WSRPC is being deprecated. Since it needs to be what terminates TLS, we're not able to use L7 load balancers with more advanced security features. Using mTLS in the Gateway would put us in a similar position. It's feasible this could be made to work with a load balancer that supports mTLS, but this wasn't greatly explored
Why auth header
Headers can be passed through from the Chainlink node, to the sidecar collector, and up to the Gateway. We can also leverage the existing CSA keys as a means of identifying nodes. Thus, using a header for authentication seemed like the path of least resistance.