Skip to content
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

Merged
merged 27 commits into from
Oct 24, 2023
Merged

Conversation

ensi321
Copy link
Contributor

@ensi321 ensi321 commented Oct 19, 2023

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 and clv included in the tokens sent to the EL clients.

Description

  • Add id: string and clv: string to JwtClaim, which are used in JsonRpcHttpClient
  • Add jwtId and jwtVersion to eth1 and execution engine options
  • Introduce --jwtId cli flag to pass the value to jwtCliam.id.
  • Auto-populate jwtVersion in eth1 and execution engine opts during beacon handler init which are used in jwtClaim.clv
  • Rename --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 automatically

They are compliant with the execution-api specs.

Closes #6016

@ensi321 ensi321 marked this pull request as ready for review October 19, 2023 14:49
@ensi321 ensi321 requested a review from a team as a code owner October 19, 2023 14:49
Copy link
Member

@nflaig nflaig left a 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

packages/beacon-node/src/eth1/provider/eth1Provider.ts Outdated Show resolved Hide resolved
packages/cli/src/options/beaconNodeOptions/execution.ts Outdated Show resolved Hide resolved
packages/cli/src/options/beaconNodeOptions/execution.ts Outdated Show resolved Hide resolved
### 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.
Copy link
Member

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.

Copy link
Contributor Author

@ensi321 ensi321 Oct 24, 2023

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

Copy link
Member

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

packages/beacon-node/src/eth1/provider/jwt.ts Outdated Show resolved Hide resolved
packages/beacon-node/src/execution/engine/http.ts Outdated Show resolved Hide resolved
packages/beacon-node/src/execution/engine/http.ts Outdated Show resolved Hide resolved
packages/cli/src/cmds/beacon/handler.ts Outdated Show resolved Hide resolved
packages/cli/src/options/beaconNodeOptions/execution.ts Outdated Show resolved Hide resolved
docs/usage/beacon-management.md Outdated Show resolved Hide resolved
packages/beacon-node/test/unit/eth1/jwt.test.ts Outdated Show resolved Hide resolved
ensi321 and others added 6 commits October 24, 2023 12:41
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.
Copy link
Contributor

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

Copy link
Member

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.

nflaig
nflaig previously approved these changes Oct 24, 2023
Copy link
Member

@nflaig nflaig left a 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

@wemeetagain
Copy link
Member

@naviechan can you confirm that --jwt-secret still works and we don't need to set an alias?

@ensi321
Copy link
Contributor Author

ensi321 commented Oct 24, 2023

@naviechan can you confirm that --jwt-secret still works and we don't need to set an alias?

Yes both --jwt-secret and --jwtSecret are correctly parsed

wemeetagain
wemeetagain previously approved these changes Oct 24, 2023
@nflaig nflaig dismissed stale reviews from wemeetagain and themself via f4996d2 October 24, 2023 15:31
@nflaig nflaig enabled auto-merge (squash) October 24, 2023 16:04
@nflaig nflaig merged commit 499fd09 into ChainSafe:unstable Oct 24, 2023
15 checks passed
@ensi321 ensi321 deleted the jwt-id branch October 26, 2023 16:22
@wemeetagain
Copy link
Member

🎉 This PR is included in v1.12.0 🎉

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Feature request: IDs for JWT claims
4 participants