Skip to content

[feature]: Security - Support file-based bitcoind RPC credentials (secrets) #10176

Closed

Description

@jkinum

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.

Activity

  1. added
    enhancementImprovements to existing features / behaviour
    on Aug 26, 2025
  2. added
    securityGeneral label for issues/PRs related to the security of the software
    backendRelated to the node backend software/interface (e.g. btcd, bitcoin-core)
    on Aug 27, 2025
  3. Roasbeef commented on Aug 28, 2025

    @Roasbeef
    Member

    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).

    Check out this project: https://github.com/lightninglabs/lndinit

  4. jkinum commented on Aug 29, 2025

    @jkinum
    Author

    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.rpcuser + bitcoind.rpcpass (static user/pass)
    • 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.

  5. bitromortac commented on Sep 2, 2025

    @bitromortac
    Collaborator

    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).

  6. jkinum commented on Sep 17, 2025

    @jkinum
    Author

    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

  7. saubyk commented on Oct 1, 2025

    @saubyk
    Collaborator

    Moving this issue to discussion. An issue can be opened up once it's taken up for development.

  8. locked and limited conversation to collaborators on Oct 1, 2025
  9. converted this issue into a discussion #10261 on Oct 1, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    backendRelated to the node backend software/interface (e.g. btcd, bitcoin-core)enhancementImprovements to existing features / behaviourfeature requestRequests for new featuressecurityGeneral label for issues/PRs related to the security of the software

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions