Giters

tendermint / tmkms

Key Management service for Tendermint Validator nodes

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Access control: validator AuthN and signing key AuthZ

tarcieri opened this issue · comments

commented

tmkms is presently a signing oracle with no AuthN/AuthZ, and though it establishes an outbound TCP connection, it will connect to any remote peer that implements the Secret Connection protocol, i.e. while Secret Connection provides AuthN in the form of Ed25519 certificates, there is presently no AuthZ around which peers can connect to the KMS or use specific keys whatsoever. (Edit: mostly implemented)

Some mechanism is needed to authorize which remote peers are allowed to use which keys, e.g. some sort of Access Control List in the configuration. While there are other methods of AuthZ which might be interesting (ocap or other credential-centric systems), for now an ACL is probably the simplest.

@zmanian had suggested tagging each key in the signing keyring with a chain ID (which was already sort of happing in an ad hoc, stringly typed manner), in which case I think the ACL can map peer IDs to chain IDs they are validators for.

This is definitely a launch blocker, but also shouldn't be that difficult to implement. (Edit: mostly implemented) We already tag validators in the configuration with their chain_id, e.g.

[[validator]]
addr = "tcp://example1.example.com:26658"
chain_id = "gaia-9000"
reconnect = true
secret_key = "path/to/secret_connection.key"

Next steps:

  • AuthN: ensure the remote peer ID matches the peer ID in the [validator] tcp:// string or else abort the connection. TODO: optional, make mandatory.
  • AuthZ: Tag every key in the keyring with a chain_id, in a first-class manner with the tendermint::chain::Id type, and partition the signing keyring by chain ID (completed in #205)
  • AuthZ: When a signing request is received, only use the keyring for that validator's chain_id
commented

The KMS side of peer verification for the validator connection is implemented as of #219, however Tendermint does not presently maintain a persistent key for the priv_validator_laddr connection so it won't be useful until it does.

Here is the relevant Tendermint issue: tendermint/tendermint#3105

commented

This was completely closed in #232, which added isolated chain-specific keyrings and therefore checked off the last item on the checkbox list in the description, which is AuthZ for using keys only on assigned chains.

A lingering problem is peer IDs for validators are not mandatory, however the proper issue for tracking that is tendermint/tendermint#3105