You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[feature]: Security - Support file-based bitcoind RPC credentials (secrets) #10176
Is your feature request related to a problem? Please describe.
When running LND and bitcoind in containers (Podman/K8s), there’s no supported way for LND to read RPC credentials from files (i.e., mounted secrets).
This causes two problems in containerized deployments:
Security boundary: Giving LND read access to Bitcoin's datadir (for the cookie) or parsing bitcoin.conf which breaks security boundaries. i.e. LND's access to another apps data and conf directories.
Secrets handling: Putting plaintext user/pass in lnd.conf is undesirable; cookies also rotate on bitcoind restart, forcing coordination or restart of LND.
Describe the solution you'd like
Credential file flags in lnd.conf.
bitcoind.rpcuserfile=/run/secrets/bitcoin-rpc-user
bitcoind.rpcpassfile=/run/secrets/bitcoin-rpc-password
LND reads file contents at startup (and ideally on SIGHUP).
Describe alternatives you've considered
Wrapper entrypoint that reads secrets and execs lnd --bitcoind.rpcuser=... --bitcoind.rpcpass=.... Works but is operationally clunky and non-declarative.
Plaintext in lnd.conf for bitcoind.rpcuser/pass. Simple but violates standard secrets hygiene.
Cookie file via bitcoind.rpccookie. Keeps plaintext out of config but requires LND to read Core’s files and handle cookie rotation.
Additional context
With bitcoin configured using rpcauth=:$, clients still authenticate with username + plaintext password that matches that rpcauth line. A file-based credential mechanism lets LND consume those values securely from a secret without leaking them into lnd.conf. The public LND docs enumerate bitcoind.rpccookie, bitcoind.rpcuser, and bitcoind.rpcpass; adding file-based variants would align with container best practices.
Thanks Roasbeef... much appreciate all the work you do to build the docker images! I might be missing something obvious but... lndinit doesn’t solve the RPC credentials problem. It appears to have been built for LND wallet initialization (seed, wallet password, migrations), not for brokering Bitcoin RPC auth. The only ways LND can authenticate to bitcoind are:
bitcoind.rpccookie (read the cookie file directly)
There’s no indirection mechanism (…file option) where lndinit could drop in a credential, and LND itself doesn’t support reading RPC credentials from Podman secrets or external sources.
Could chart templating be used to solve this? Maybe an alternative is to overload bitcoind.rpcuser/bitcoind.rpcpass to check for existing files (--bitcoind.rpcpass=file:/run/secrets/bitcoin-rpc-password or similar) and read credentials from those (to avoid having to add more configuration options, which should be added for btcd as well for consistency).
Activity
Roasbeef commentedon Aug 28, 2025
Check out this project: https://github.com/lightninglabs/lndinit
jkinum commentedon Aug 29, 2025
Thanks Roasbeef... much appreciate all the work you do to build the docker images! I might be missing something obvious but... lndinit doesn’t solve the RPC credentials problem. It appears to have been built for LND wallet initialization (seed, wallet password, migrations), not for brokering Bitcoin RPC auth. The only ways LND can authenticate to bitcoind are:
There’s no indirection mechanism (…file option) where lndinit could drop in a credential, and LND itself doesn’t support reading RPC credentials from Podman secrets or external sources.
bitromortac commentedon Sep 2, 2025
Could chart templating be used to solve this? Maybe an alternative is to overload
bitcoind.rpcuser/bitcoind.rpcpassto check for existing files (--bitcoind.rpcpass=file:/run/secrets/bitcoin-rpc-passwordor similar) and read credentials from those (to avoid having to add more configuration options, which should be added for btcd as well for consistency).jkinum commentedon Sep 17, 2025
Reading the RPC credentials from an env variable might be an option as well and avoid the concern raised by @bitromortac
Secret=bitcoin-rpc-password,type=env,target=BITCOIN_RPC_PASSWORD
Secret=bitcoin-rpc-user,type=env,target=BITCOIN_RPC_USER
saubyk commentedon Oct 1, 2025
Moving this issue to discussion. An issue can be opened up once it's taken up for development.