Skip to main content

Securing Treasury

Treasury should be deployed in a zero trust model; only the minimum functionality needed is exposed.

Encryption at rest​

Keys in treasury are generated on demand and use encryption at rest. This means no secret information will be present on disk. The decryption key can be loaded live from a secret manager or environment variable.

To use, make sure you have encryption-at-rest enabled.

# set SIGNER_NEW_EAR_PHRASE
cord ear encrypt-in-place

Then be sure to use --ear-reference <reference> when you launch cord supervise run .... As of this writing, you can use the follow secret references.

  • Environment variable env:<name>
  • Hashicorp Vault vault:<server-url>,<path>
  • Google Secret Manager gsm:<project>,<name>[,version]
  • AWS Secret Manager aws:<name>[,region][,version]

To test your secret is loading, you can use cord test secret --help

Network topology​

Treasury has three important network TCP ports.

  • 7867: This is the MPC port. Used by all Treasury nodes to communicate for MPC. Communication at this layer is end-to-end encrypted. The credentials needed to partake in communication are generated during the initial setup.

  • 26656: This is the consenus port. All Treasury nodes use this to gossip new transactions and come to a consensus on new states (policies) for the Treasury as a whole. Only validators are allowed to propose new changes, using credentials generated during the initial setup. No key material is used by applications communicating on this channel (aside from the validator key).

  • 8777: This in the API port. It implements the Treasury API and forwards requests to a connected Treasury node using the consensus port.

Both the consensus and MPC ports are required connections between all Treasury nodes. The API port is the only connection required for external applications or users to use for Treasury.

Simple 2 node configuration​

The simplest configuration would be to expose the API port on one of the participating Treasury nodes.

Simple configuration

It may be best to start with this simple two node configuration, test everything works, and then proceed with hardening it.

Hardened 2 node configuration​

A more hardened configuration would be to not expose any ports on the secure Treasury nodes and instead, setup a "sentry" machine to expose the API. The API node should then be configured to connect to one or more of the participating nodes. Or alternatively, one or more of the Treasury nodes can be configured to reach out to connect to the API node (all incoming connections can then be blocked on Treasury nodes).

Hardened configuration

An API node can be setup after the Treasury nodes are running.

HTTPS​

The Treasury API (default port 8777), should be exposed using HTTPS in order to work with the web UI. There are a number of ways to do this by using a reverse proxy. The best way depends on your infrastructure.

This is because the UI is hosted on HTTPS, and modern browsers do not permit plain HTTP requests while on an HTTPS domain.

A temporary workaround could be to port forward from localhost, and then connect the UI to localhost. Some browsers, like Chrome, permit plain HTTP requests to localhost.

ssh -L 8777:localhost:8777 "<user>"@"<hostname>"

FAQ​

What is the risk if the MPC or consensus ports get exposed?​

Both connections require credentialed access, so this would not cause an incident by itself. It's best to keep them closed off externally to follow a zero trust model.

How does an API node forward requests?​

It uses it's consensus connection(s) to fully replicate the policy state, and any queries will be executed on that replicated state.

Signed HTTP requests (POST, PUT, DELETE) will be forwarded (or "gossiped") to the Treasury nodes to be independently validated.

How do I run an API service/node?​

It's the same as running a Treasury node, but it doesn't have any keys or voting power. It cannot participate in MPC nor can it meaningfully vote on any changes in consensus.

See the guide on running an API node.

Where does the connector run?​

The connector is a service that may run in a Treasury node that just relays information between Treasury and public blockchains. It can run in any Treasury node, and at least one Treasury node must be enabled to run with the connector service. It's recommended that the API service runs the connector - then none of the Treasury nodes needs internet access, except for when pulling new updates.

Without the connector running, blockchain transactions will get stuck in the 'preparing' state.