a44bf0cb0c
Create the signing01.ci.openstack.org job node and puppet the signing subkey onto it via pubring.gpg and secring.gpg files stored in private hiera. Also set up some basic configuration and packages on the management bastion to aid in key management/rotation, and add the beginnings of administrative documentation for this. Change-Id: Iecddb778994a38f7898e0c20e7f3f8e93f0a7f60 Depends-On: I70c3b82185681ee64791cda653360c26a93bd466 Story: #2000336 Signed-off-by: Jeremy Stanley <fungi@yuggoth.org>
88 lines
3.1 KiB
ReStructuredText
88 lines
3.1 KiB
ReStructuredText
:title: Signing System
|
|
|
|
.. _signing:
|
|
|
|
Signing System
|
|
##############
|
|
|
|
This machine corresponds to the ``signing`` node label in job
|
|
configuration, holding an unencrypted copy of the OpenPGP signing
|
|
subkey for ``OpenStack Infra (Some Cycle)
|
|
<infra-root@openstack.org>`` used to create detached signatures for
|
|
release artifacts (tarballs, wheels, et cetera) and to sign and push
|
|
Git tags as part of our managed release automation. It only runs CI
|
|
jobs for tasks which require access to this key, using only vetted
|
|
tools and scripts reviewed by the Infra team.
|
|
|
|
|
|
At a Glance
|
|
===========
|
|
|
|
:Hosts:
|
|
* signing*.ci.openstack.org
|
|
:Puppet:
|
|
* :file:`modules/openstack_project/manifests/signing_node.pp`
|
|
|
|
|
|
Key Management Overview
|
|
=======================
|
|
|
|
The signing server is a fairly typical long-lived job node,
|
|
distinguished primarily by having the signing subkey pair installed
|
|
by Puppet into the job runner account's home directory from binary
|
|
blobs in hiera. These blobs correspond to the
|
|
``~/.gnupg/pubring.gpg`` and ``~/.gnupg/secring.gpg`` files of a
|
|
freshly initialized gpg config after importing a minimal unencrypted
|
|
export on the management bastion of only the desired signing subkey
|
|
from the ``/root/signing.gunpg`` directory.
|
|
|
|
|
|
Storage
|
|
-------
|
|
|
|
While the signing subkey is present unencrypted on this system, the
|
|
corresponding master key is kept symmetrically encrypted in the root
|
|
home directory of the Infra systems management bastion instead. At
|
|
the time of key creation a revocation certificate is also generated,
|
|
for which Infra root sysadmins are encouraged to retrieve and keep
|
|
local copies in case control over or access to the original master
|
|
key is lost. In the future, the master key and revocation
|
|
certificate may be distributed across our root team rather than kept
|
|
in one place (for example using Shamir's secret sharing scheme
|
|
similar to what `the Debian Project does for its archive keys
|
|
<https://ftp-master.debian.org/keys.html>`).
|
|
|
|
|
|
Rotation
|
|
--------
|
|
|
|
The master key is rotated at the start of each development cycle,
|
|
signed by a majority of Infra root sysadmins before being put into
|
|
service, and has an expiration date set for shortly after the end of
|
|
the targeted development cycle. As each new key is created and
|
|
brought into rotation, an announcement should be signed by both the
|
|
old and new keys and sent to the
|
|
openstack-announce@lists.openstack.org mailing list. The new key
|
|
should also be signed by the old, and this signature pushed to the
|
|
public keyserver network. New key fingerprints are also submitted to
|
|
the openstack/releases repository, for publication on the
|
|
releases.openstack.org Web site.
|
|
|
|
|
|
Revocation
|
|
----------
|
|
|
|
Under normal circumstances, keys should be allowed to expire
|
|
gracefully. If the key is compromised but still accessible, a
|
|
revocation certificate can be generated and published to the key
|
|
network at that time. If access to the private key is lost
|
|
completely, the revocation certificate generated at key creation
|
|
time should be used as a last resort.
|
|
|
|
|
|
Management
|
|
==========
|
|
|
|
As process is solidified, this section will be updated with specific
|
|
commands and examples.
|