93c11e0e53
* Update rules_go * go 1.15 * try with v0.24.2 * Update Mac OS X SDK * gaz * update SDK in toolchain config * -I flag * another -I flag * Update rules_go, gazelle, bazel version * regen, update rules_docker * Revert "another -I flag" This reverts commit 9255133d99bee1e94560a64316a4a7539a363935. * Revert "-I flag" This reverts commit 2954a41d76adc81ccb6281af243f4be1f79152e9. * giving up * Use OS X 10.12 * Use OS X 10.12 * Revert "Use OS X 10.12" This reverts commit 4f60d5cb807b2ccccd484a85a6a7477a5fd13e28. * Revert "Use OS X 10.12" This reverts commit a79177fab7182ad792d1cee7fb61214ef8bd73ab. * osx toolchain tweaks necessary to work with 10.15 mac sdk * Update docker image, regen * gaz * test using custom image * Revert "test using custom image" This reverts commit 95b8666810a254f16061c99e2ea0ae4d020b2f2d. * explicit go version * Clean up docker image rules with new definitions. gazelle * please the linter * Update protobuf compiler to 3.13.0, run gazelle * Update gazelle to fix empty build files. https://github.com/bazelbuild/bazel-gazelle/pull/926 * update skylib * fix herumi fuzz build * remove comment from tools/cross-toolchain/regenerate.sh Co-authored-by: rkapka <rkapka@wp.pl> Co-authored-by: SuburbanDad <gts.mobile@gmail.com> Co-authored-by: prylabs-bulldozer[bot] <58059840+prylabs-bulldozer[bot]@users.noreply.github.com> |
||
|---|---|---|
| .. | ||
| client | ||
| server | ||
| README.md | ||
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
- Request
nprivate keys from the pk manager. - If unallocated private keys exist (from previously terminated pods), assign to the requesting pod.
- If there are not at least
nkeys not in use, generate new private keys, and make the deposits on behalf of these newly generated private keys. - Write the key allocations to a persistent datastore and fulfill the request.
- 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.