prysm-pulse/tools/cluster-pk-manager
Preston Van Loon 49a0d3caf0
Refactor dependencies, make Prysm "go gettable" (#6053)
* Fix a few deps to work with go.mod, check in generated files

* Update Gossipsub to 1.1 (#5998)

* update libs

* add new validators

* add new deps

* new set of deps

* tls

* further fix gossip update

* get everything to build

* clean up

* gaz

* fix build

* fix all tests

* add deps to images

* imports

Co-authored-by: rauljordan <raul@prysmaticlabs.com>

* Beacon chain builds with go build

* fix bazel

* fix dep

* lint

* Add github action for testing go

* on PR for any branch

* fix libp2p test failure

* Fix TestProcessBlock_PassesProcessingConditions by updating the proposer index in test

* Revert "Fix TestProcessBlock_PassesProcessingConditions by updating the proposer index in test"

This reverts commit 43676894ab01f03fe90a9b8ee3ecfbc2ec1ec4e4.

* Compute and set proposer index instead of hard code

* Add back go mod/sum, fix deps

* go build ./...

* Temporarily skip two tests

* Fix kafka confluent patch

* Fix kafka confluent patch

* fix kafka build

* fix kafka

* Add info in DEPENDENCIES. Added a stub link for Why Bazel? until https://github.com/prysmaticlabs/documentation/issues/138

* Update fuzz ssz files as well

* Update fuzz ssz files as well

* getting closer

* rollback rules_go and gazelle

* fix gogo protobuf

* install librdkafka-dev as part of github actions

* Update kafka to a recent version where librkafkfa is not required for go modules

* clarify comment

* fix kafka build

* disable go tests

* comment

* Fix geth dependencies for end to end

* rename word

* lint

* fix docker

Co-authored-by: Nishant Das <nishdas93@gmail.com>
Co-authored-by: rauljordan <raul@prysmaticlabs.com>
Co-authored-by: terence tsao <terence@prysmaticlabs.com>
2020-05-31 14:44:34 +08:00
..
client libfuzz based tests (#5095) 2020-05-05 07:22:26 +00:00
server Refactor dependencies, make Prysm "go gettable" (#6053) 2020-05-31 14:44:34 +08:00
README.md Update cluster pk manager to assign multiple keys to validators (#2112) 2019-04-14 17:53:34 -04:00

Cluster private key management tool

This is a primative tool for managing and delegating validator private key assigments within the kubernetes cluster.

Design

When a validator pod is initializing within the cluster, it requests a private key for a deposited validator. Since pods are epheremal, scale up/down quickly, there needs to be some service to manage private key allocations, validator deposits, and re-allocations of previously in-use private keys from terminated pods.

Workflow for bootstraping a validator pod

  1. Request n private keys from the pk manager.
  2. If unallocated private keys exist (from previously terminated pods), assign to the requesting pod.
  3. If there are not at least n keys not in use, generate new private keys, and make the deposits on behalf of these newly generated private keys.
  4. Write the key allocations to a persistent datastore and fulfill the request.
  5. The client uses these private keys to act as deposited validators in the system.

Server

The server manages the private key database, allocates new private keys, makes validator deposits, and fulfills requests from pods for private key allocation.

Database structure

There are two buckets for the server, unallocated keys and allocated keys.

Unallocated keys bucket:

key value
private key nil

Allocated keys bucket:

key value
pod name list of private keys

Key management design

There are two types of operations with regards to private keys:

  • Allocate(podName, keys)
  • UnallocateAllKeys(podName)

Allocating keys will first check and attempt to recycle existing, unused keys. If there are no unused keys available (or not enough), new keys are deposited.

Unallocating keys happens when a pod is destroyed. This should return all of that's pods' keys to the unallocated keys bucket.

Assignments HTTP Page /assignments

The server exposes an HTTP page which maps pod names to public keys. This may be useful for determining which logs to follow for a given validator.

Client

The client makes the private key request with a given pod name and generates a keystore with the server response.