-
Notifications
You must be signed in to change notification settings - Fork 8
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Co-authored-by: Paul Meyer <[email protected]>
- Loading branch information
1 parent
392696f
commit d6817d8
Showing
4 changed files
with
55 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,24 @@ | ||
# Secrets & recovery | ||
|
||
When the Coordinator is configured with the initial manifest, it generates a random secret seed. | ||
From this seed, it uses an HKDF to derive the CA root key and a signing key for the manifest history. | ||
This derivation is deterministic, so the seed can be used to bring any Coordinator to this Coordinator's state. | ||
|
||
The secret seed is returned to the user on the first call to `contrast set`, encrypted with the user's public seed share owner key. | ||
If no seed share owner key is provided, a key is generated and stored in the working directory. | ||
|
||
## Persistence | ||
|
||
The Coordinator runs as a `StatefulSet` with a dynamically provisioned persistent volume. | ||
This volume stores the manifest history and the associated runtime policies. | ||
The manifest isn't considered sensitive information, because it needs to be passed to the untrusted infrastructure in order to start workloads. | ||
However, the Coordinator must ensure its integrity and that the persisted data corresponds to the manifests set by authorized users. | ||
Thus, the manifest is stored in plain text, but is signed with a private key derived from the Coordinator's secret seed. | ||
|
||
## Recovery | ||
|
||
When a Coordinator starts up, it doesn't have access to the signing secret and can thus not verify the integrity of the persisted manifests. | ||
It needs to be provided with the secret seed, from which it can derive the signing key that verifies the signatures. | ||
This procedure is called recovery and is initiated by the workload owner. | ||
The CLI decrypts the secret seed using the private seed share owner key, verifies the Coordinator and sends the seed through the `Recover` method. | ||
The Coordinator recovers its key material and verifies the manifest history signature. |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters