@@ -59,6 +59,9 @@ An exception is the ``private-keys`` directory in the ``local`` morph grid:
That directory is fully populated, provided as an example, and mostly: not very secret.
Do not deploy these keys to machines reachable via the internet.
Strictly speaking,
this path is configurable in the grid's ``config.json`` but all three grids currently use this name.
public-keys
~~~~~~~~~~~
...
...
@@ -67,6 +70,29 @@ This must be created and populated before the grid can be built or deployed.
This directory contains any public key material necessary for operation of the grid.
This includes the public keys corresponding to any private keys held in ``private-keys``.
As for ``private-keys``,
this path can be configured in the grid's ``config.json``.
Star-crossed Keys
^^^^^^^^^^^^^^^^^
Where the system uses keypairs,
the public and private parts of those keypairs are stored in different locations
(``public-keys`` and ``private-keys`` mentioned above).
This somewhat complicates key management because any key rotation involves changing key material in two location instead of just one.
This complication is balanced against a specific operational goal:
that our build systems operate without copies of our private keys.
Our system configurations do currently have build-time dependencies on public keys.
Splitting public keys and private keys across two different storage locations provides a simple mechanism for providing build systems with the public keys but withholding the private keys.
In the future we may:
* be sufficiently confident in the security of our build systems to let them have our private keys; or
* remove the dependency upon public keys from the build process.
Either of these directions would let us re-unify public/private-key storage and remove this complication.
