Bitcoind to use RPC authentication cookie from file

schildbach commented at 8:47 am on November 14, 2020: contributor

I’m running bitcoind 0.20.1 inside a Docker container and would like to access its RPC interface from another container.

Docker has a way to manage secrets like the RPC authentication cookie and safely pass them between containers. Effectively, it mounts the secret as a file like /run/secrets/rpc_cookie. I’d like bitcoind to use the cookie from that file.

I tried -rpccookiefile=/run/secrets/rpc_cookie, but bitcoind tries to write to that file and fails. Of course, it’s read-only.

Alternatives: Docker doesn’t support to insert secrets (which can be any data, including binary) into configuration files or to pass it as a command line argument (which would leak the cookie anyway, I guess).

Proposal: I propose adding a mode in which bitcoind reads the authentication cookie from file, rather than trying to create a new one. That mode could be auto-enabled if the specified cookie file exists on startup and is read-only.

Side note: Because of at least one consumer of the RPC API (electrs) only supports reading cookies from file (both command like arguments and environment variables are deemed insecure), I will now have to define the same secret at two places – which I think has a higher risk to leak the secret.

schildbach added the label Feature on Nov 14, 2020

ryanofsky commented at 11:04 am on November 16, 2020: contributor

This seems like a good thing to support, but maybe it would be cleaner to use password authentication instead of cookie authentication here. Cookies being secrets chosen by the server, and passwords being secrets chosen externally. But if not getting caught up in cookie/password semantics, we could add a -rpccookiegenerate/-norpccookiegenerate boolean option defaulting to true, to toggle between either generating the cookie internally or allowing a cookie value to be specified externally. I think adding an option to use external cookies would be better than automatically trusting read-only cookie files, which might be created unintentionally or maliciously.

Another suggestion to solve the immediate problem of using bitcoin and electrs with docker secrets: maybe you could have docker generate /run/secrets/bitcoin_password and have a startup script include it in electrs and bitcoind configurations (bitcoin -includeconf option might be useful here).

promag commented at 11:38 am on November 16, 2020: member

0  -conf=<file>
1       Specify path to read-only configuration file. Relative paths will be
2       prefixed by datadir location. (default: bitcoin.conf)

Make the whole conf file a secret with desired rpcauth=... credentials. Same for electrs.

schildbach commented at 10:05 pm on November 16, 2020: contributor

@ryanofsky I thought rpc passwords are going to go away? They’re already deprecated in current bitcoind. I agree with your concern about the implicit toggle. @promag I thought of that too, but putting the entire configuration into a secret seems like an abuse of the secrets mechanism. For example, conf files do not support Docker compose variable substitution, as opposed to config via arguments or environment variables.

sipa commented at 10:07 pm on November 16, 2020: member

@schildbach -rpcpassword/-rpcuser is deprecated. The new mechanism is -rpcauth, which uses the same internal mechanism as the cookie logic (but supports configuring using externally generated passwords).

promag commented at 10:13 pm on November 16, 2020: member

conf files do not support Docker compose variable substitution, as opposed to config via arguments or environment variables. @schildbach those can be set as the command (beside -conf) right?

schildbach commented at 10:19 pm on November 16, 2020: contributor

@schildbach -rpcpassword/-rpcuser is deprecated. The new mechanism is -rpcauth, which uses the same internal mechanism as the cookie logic (but supports configuring using externally generated passwords).

Exactly, and this feature request is about reading the new RPC auth cookie from a file.

promag commented at 10:28 pm on November 16, 2020: member

@schildbach hare you tried to use docker compose volumes_from?

promag commented at 10:33 pm on November 16, 2020: member

Anyway, I’m concept NACK on this. I think we could support -rpcauth=path instead.

Edit: since -rpcauth is considered sensitive then I’d suggest -rpcauthfile=path.

maflcko commented at 7:32 am on November 17, 2020: member

but putting the entire configuration into a secret seems like an abuse of the secrets mechanism

It doesn’t have to be the whole config. It can be just an -includeconf which contains just one line with the rpcauth blob

schildbach commented at 4:44 pm on November 17, 2020: contributor

Thanks for the hint. It still feels kludgy and unsafe though. I don’t want the secret to be able to add arbitrary configuration to my bitcoind. Note that secrets are not meant to be reviewed, while configuration is like code in that it should be seen by as many eyes as possible.

promag commented at 4:45 pm on November 17, 2020: member

@schildbach feel free to test #20407.

alevchuk commented at 4:27 pm on June 2, 2022: none

This seems to go against the purpose of the cookie file. To avoid another account capturing the password, the cookie file needs to be regenerated every time bitcoind restarts. Also, it needs to be generated after bitcoind binds to the RPC port, so the best place to do generation is inside bitcoind

thinkmassive commented at 7:43 pm on January 11, 2023: none

putting the entire configuration into a secret seems like an abuse of the secrets mechanism.

It seems like rpcauthfile (proposed in #20407) could be valuable in a Kubernetes environment, where the cookie approach might be less viable, and storing the rpcauth string in plaintext in the config file is obviously less secure (but likely, when the entire config is stored as a secret).

The rpcauth string could be stored as a secret on its own, which can be fetched and provided for one-time use at startup from a named pipe that disappears from the filesystem after being read once. This approach seems even more secure than using a cookie file, which persists on the filesystem during operation.

willcl-ark commented at 3:06 pm on October 14, 2024: member

It seems like the consensus is that one should use rpcauth in this situation.

Let us know if you feel this should be reopened.

willcl-ark closed this on Oct 14, 2024

Bitcoind to use RPC authentication cookie from file #20387