Allow provisioning of the api-token.txt file (HTTP server auth)

[jvbriones]

Description

To communicate via HTTP a Bearer token is needed which is generated at the startup and placed in validators-dir/api-token.txt. This HTTP communication is now required for some actions, e.g. after #3264, the only way now to update the fee recipient config is via Key Manager API.

The api-token.txt file is re-generated when restarting the service even if the file already exists in the expected location. This is problematic when automating the configuration of the system resulting in 403 HTTP responses due a change of the token.

This approach does not allow you to provision a specific token used by the different services that consume the validator and communicate via HTTP.

It would be better if we could provision the token as we already do with the JWT token needed for the EL communication.

Version

docker - v2.5.1-modern

Present Behaviour

The api-token.txt file is re-generated when restarting the service.

Expected Behaviour

Generate api-token.txt file only if is missing.

[michaelsproul]

This is on our long-term TODO list, so I'll leave this issue open, however if you'd like an immediate workaround you can provision the API token if you generate a valid secp256k1 keypair.

Lighthouse's API token is actually serving a dual purpose, it acts as both a shared secret and the public key for the validator client's signed responses. There's some information on the signing process here. If you'd like to keep the same key across restarts you need to generate (or persist) two files:

• .secp-sk: an secp256k1 private key stored as 0x-prefixed hex
• api-token.txt: an secp256k1 public key stored as api-token-0x{pubkey}

In other words, the api-token.txt cannot just be arbitrary bytes, if it isn't part of a valid keypair then the VC will generate a new keypair and overwrite it.

[jmcruz1983]

Thanks @michaelsproul for the workaround,
I am just wondering how this would work together with lighthouse validator using a remove web3signer,
would this key pair conflict in some way?

[michaelsproul]

Hey @jmcruz1983, I don't think there's any conflict even when using web3signer, the VC just needs an arbitrary secp256k1 key on disk to sign the HTTP responses. If you don't care about those signatures (and most people don't) then there's no need to have that signing key come from web3signer. Those signature on the HTTP response just prove to the caller that it is communicating with the authentic issuer of the API token. Most other consensus clients don't have any mechanism for proving VC authenticity AFAIK. It's mostly the other direction that's important (proving the caller is authorised to talk to the VC).

[michaelsproul]

Related:

• Remove VC response signing #5423

[michaelsproul]

The token is now an arbitrary text value and can be provisioned more easily.