-
-
Notifications
You must be signed in to change notification settings - Fork 291
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: add optional id and clv to JWT claims #6052
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just some initial thoughts
docs/usage/beacon-management.md
Outdated
### Set up and include identifiers in JWT tokens | ||
|
||
Lodestar auto-populates `clv` field in the claims of JWT authentication tokens with a non-configurable value `Lodestar/$CLIENT_VERSION` eg. `Lodestar/v1.3.0/2d0938e` to communicate the client's version. Lodestar also optionally includes `id` field in the claims with value `$JWT_ID` if the appropriate flag `--jwtId $JWT_ID` is added. | ||
`id` and `clv` are particularly useful when running multiple consensus-layer clients with the different JWT secrets which makes the execution-layer client difficult to choose which JWT secret to verify against due to the inability to distinguish between the different consensus-layer clients. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This might be confusing, as far as I am aware execution clients do not natively support multiplexing of consensus clients and I don't think this will ever be something that will be implemented. Without a multiplexer middleware like eleel it is not recommended to connect multiple CLs to a single EL.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This might be confusing, as far as I am aware execution clients do not natively support multiplexing of consensus clients and I don't think this will ever be something that will be implemented. Without a multiplexer middleware like eleel it is not recommended to connect multiple CLs to a single EL.
I thought about the possible use case of configuring --jwtId
for normal users and I can't think of any. The multiplexer case is nice but users who read this doc probably won't ever need it.
I am inclined to just remove this entirely because the point of this doc is to set up a beacon node. Explaining things in jwt claim and the option to add id
because of multiplexer seem really out of place in the doc.
Man writing user doc is hard
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The multiplexer case is nice but users who read this doc probably won't ever need it.
Yeah, I rather see people using eleel come to the CLI reference to see if Lodestar has the option to set the jwt id
I am inclined to just remove this entirely because the point of this doc is to set up a beacon node.
+1, I think should keep it simple here
Man writing user doc is hard
Defintiely hard thing because it is quite subjective and user feedback is required in a lot of cases, @matthewkeil is working on a docs restructuring which should make it clearer on what details to include where.
In my opinion
- step-by-step instructions should mostly omit unnecessary details
- while sections explaining different concepts can go more into detail
Co-authored-by: Nico Flaig <nflaig@protonmail.com>
Co-authored-by: Nico Flaig <nflaig@protonmail.com>
Co-authored-by: Nico Flaig <nflaig@protonmail.com>
Co-authored-by: Nico Flaig <nflaig@protonmail.com>
Co-authored-by: Nico Flaig <nflaig@protonmail.com>
@@ -33,7 +33,12 @@ You must generate a secret 32-byte (64 characters) hexadecimal string that will | |||
|
|||
### Configure Lodestar to locate the JWT secret | |||
|
|||
When starting up a Lodestar beacon node in any configuration, ensure you add the `--jwt-secret $JWT_SECRET_PATH` flag to point to the saved secret key file. | |||
When starting up a Lodestar beacon node in any configuration, ensure you add the `--jwtSecret $JWT_SECRET_PATH` flag to point to the saved secret key file. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why change this flag? I think yargs supports both notations and the --jwt-secret
flag is kind of standarized across clients
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
kind of standarized across clients
Kinda, but not really
- Teku:
--ee-jwt-secret-file
(ref) - Lighthouse:
--execution-jwt
(ref) - Prsym:
--jwt-secret
(ref) - Nimbus:
--jwt-secret
(ref)
For Lodestar, --jwt-secret
is currently the only commonly used flag which uses different casing. I'd recommend we use the same standard (camelCase) for this flag as well.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm, thanks for all the updates
@naviechan can you confirm that |
Yes both |
🎉 This PR is included in v1.12.0 🎉 |
Motivation
When running multiple CL clients with different JWT secrets, it is difficult for EL clients to identify which JWT secrets to verify against which could be solved by having identifiers such as
id
andclv
included in the tokens sent to the EL clients.Description
id: string
andclv: string
to JwtClaim, which are used inJsonRpcHttpClient
jwtId
andjwtVersion
to eth1 and execution engine options--jwtId
cli flag to pass the value tojwtCliam.id
.jwtVersion
in eth1 and execution engine opts during beacon handler init which are used injwtClaim.clv
--jwt-secret
to--jwtSecret
for the sake of being consistent with naming convention of other flags. Note this change is backward compatible since yargs handles hyphen case and camel case automaticallyThey are compliant with the execution-api specs.
Closes #6016