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

Decide on policy enforcement location #4

Open
aakselrod opened this issue May 10, 2023 · 0 comments
Open

Decide on policy enforcement location #4

aakselrod opened this issue May 10, 2023 · 0 comments

Comments

@aakselrod
Copy link
Member

We need to decide on how and where to enforce policy on PSBT signing requests (and perhaps other requests as well). This decision is likely to be affected by reversing the remote signer connection.

Currently, we have a two-part signer: one is the vault-plugin-lndsigner and the other is lndsignerd that is meant to live in a sidecar with lnd. Policy is enforced in the sidecar in lndsignerd, because it's easy to ship information about state there. The sidecar gets the actual digests for the vault-plugin-lndsigner to sign and sends them for signatures. This isn't the ideal situation, as the decision to sign or not sign is made very close to the publicly-accessible lnd instance.

One alternative is to move the policy enforcement to the vault plugin. This means the sidecar would ship all the requests there, including PSBT data and blockchain/channel state updates. The caveat is that vault is not optimized for write-heavy workloads such as those required to keep channel state for a busy node (or multiple busy nodes). In instances where the vault deployment is geographically distributed, it would be especially difficult to keep channel state synchronized across the deployment for busy nodes.

Another alternative would be to introduce yet another executable component for policy enforcement between the sidecar and vault. Then the vault plugin can remain stateless and the sidecar would only forward the requests and required state updates to the policy enforcement component. The new component would live in a more protected part of the network, and could potentially be multi-tenant like the vault plugin if desired. It could store state in a database such as PostgreSQL. lndsignerd could authenticate to the new component using mTLS.

A third alternative is to situate the lndsignerd farther from the lnd node in deployments. A caveat is that we would need to figure out authentication/authorization between lnd and lndsignerd without the benefit of the sidecar environment. This would let us ensure that the policy enforcement decisions are made in a more secure environment while still restricting API requests to only the lnd instance. The lndsignerd instance could still be single-tenant as now, and could store its data in a database such as PostgreSQL.

There are probably additional alternatives we can come up with.

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

No branches or pull requests

1 participant