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
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.
The text was updated successfully, but these errors were encountered:
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 islndsignerd
that is meant to live in a sidecar withlnd
. Policy is enforced in the sidecar inlndsignerd
, because it's easy to ship information about state there. The sidecar gets the actual digests for thevault-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-accessiblelnd
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 thatvault
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 thevault
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 thevault
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 thelnd
node in deployments. A caveat is that we would need to figure out authentication/authorization betweenlnd
andlndsignerd
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 thelnd
instance. Thelndsignerd
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.
The text was updated successfully, but these errors were encountered: