Merge "Artifact Signing Toolchain"
This commit is contained in:
Jenkins
Gerrit Code Review
commit
43b3c69ed9
|
|
@ -36,6 +36,7 @@ permits.
|
|||
:maxdepth: 1
|
||||
|
||||
specs/ansible_puppet_apply
|
||||
specs/artifact-signing
|
||||
specs/centralize-release-tagging
|
||||
specs/code-search
|
||||
specs/doc-publishing
|
||||
|
|
|
|||
|
|
@ -0,0 +1,175 @@
|
|||
::
|
||||
|
||||
Copyright 2015 OpenStack Foundation
|
||||
|
||||
This work is licensed under a Creative Commons Attribution 3.0
|
||||
Unported License.
|
||||
http://creativecommons.org/licenses/by/3.0/legalcode
|
||||
|
||||
==========================
|
||||
Artifact Signing Toolchain
|
||||
==========================
|
||||
|
||||
https://storyboard.openstack.org/#!/story/2000336
|
||||
|
||||
The OpenStack Community will publish cryptographic signatures
|
||||
accompanying release artifacts (tarballs, packages, et cetera) to
|
||||
provide a verification of provenance.
|
||||
|
||||
Problem Description
|
||||
===================
|
||||
|
||||
Unlike our Git repositories, where releases are represented by
|
||||
cryptographic signatures of release managers embedded in tags, the
|
||||
artifacts built in our infrastructure from those tagged repository
|
||||
states come with no proof of their origin. Files uploaded to our
|
||||
tarballs site or external services lack any attestation that they're
|
||||
unmodified since the time of their original creation and
|
||||
publication. This allows, among other risks, the possibility that a
|
||||
published release can be altered either accidentally or by a
|
||||
malicious actor.
|
||||
|
||||
Proposed Change
|
||||
===============
|
||||
|
||||
Add a dedicated job worker responsible for performing artifact
|
||||
signing between the generation and publication steps.
|
||||
|
||||
Alternatives
|
||||
------------
|
||||
|
||||
* As always, we could do nothing, though the problem remains.
|
||||
* We could engineer a system whereby individuals vet release
|
||||
artifacts and upload their own individual attestations, though
|
||||
that's not necessary precluded by the proposed solution anyway and
|
||||
could operate in parallel if desired.
|
||||
|
||||
Implementation
|
||||
==============
|
||||
|
||||
Assignee(s)
|
||||
-----------
|
||||
|
||||
Primary assignee:
|
||||
fungi
|
||||
|
||||
Gerrit Topic
|
||||
------------
|
||||
|
||||
Use Gerrit topic "artifact-signing" for all patches related to this
|
||||
spec.
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
git-review -t artifact-signing
|
||||
|
||||
Work Items
|
||||
----------
|
||||
|
||||
1. Generate OpenPGP keypair with signing subkey, both set to expire
|
||||
at the beginning of the next development cycle; store the master
|
||||
private key and a revocation certificate with our other service
|
||||
credentials; add the subkey in hiera
|
||||
2. Get all infra root admins to sign the artifact signing key and
|
||||
publish those signatures to the keyserver network
|
||||
3. *openstack-infra/system-config*:
|
||||
|
||||
1. Create a puppet class and node definition for
|
||||
signing.slave.openstack.org
|
||||
2. Add basic documentation of the infra root process for handling
|
||||
of the artifact signing key (infra root keysigning,
|
||||
publishing, extending the expiration date, and emergency
|
||||
revocation)
|
||||
|
||||
4. Launch the new signing.slave.openstack.org server
|
||||
5. *openstack-infra/system-config*: Add signing.slave.openstack.org
|
||||
to cacti
|
||||
6. Register the signing.slave.openstack.org in jenkins.openstack.org
|
||||
and add a ``signing`` label to it
|
||||
7. *openstack-infra/project-config*:
|
||||
|
||||
1. Develop a slave script for signing automation and integrate it
|
||||
into the openstack-infra/project-config repo (this could be an
|
||||
extension of or abstraction from some of the existing
|
||||
``*-upload.sh`` scripts)
|
||||
2. Add a job to identify the artifact name (based on the tag and
|
||||
details within the repo, or just the tag and have multiple
|
||||
similar jobs), retrieve it, create a detached signature and
|
||||
then upload it back to an adjacent path
|
||||
3. Extend the release upload jobs/job-templates to retrieve,
|
||||
validate and incorporate detached signatures, at least for
|
||||
reuploads to external services which currently support it
|
||||
|
||||
8. *openstack/governance* and/or *openstack/ossa*: Add documentation
|
||||
of the existence of artifact signatures and instructions on
|
||||
validating them
|
||||
9. Send an announcement to the
|
||||
openstack-announce@lists.openstack.org mailing list informing the
|
||||
community of the availability of signatures accompanying all
|
||||
upcoming releases
|
||||
|
||||
Repositories
|
||||
------------
|
||||
|
||||
No new git repositories need to be created.
|
||||
|
||||
Servers
|
||||
-------
|
||||
|
||||
A new signing.slave.openstack.org server needs to be created. No
|
||||
existing servers will be affected.
|
||||
|
||||
DNS Entries
|
||||
-----------
|
||||
|
||||
DNS entries (A/AAAA/PTR) for signing.slave.openstack.org need to be
|
||||
created.
|
||||
|
||||
Documentation
|
||||
-------------
|
||||
|
||||
We will need documentation for key handling/signing/rotation in the
|
||||
openstack/system-config repo, outlining the process followed by
|
||||
infra root admins. Documentation in either the openstack/governance
|
||||
or openstack/ossa repos should probably also be created explaining
|
||||
the existence of our artifact signatures and how they can be
|
||||
validated. There is no anticipated impact to our current developer
|
||||
workflow. An announcement is warranted once the implementation is in
|
||||
place and confirmed working as intended.
|
||||
|
||||
Security
|
||||
--------
|
||||
|
||||
There are associated security risks, but they are not regressions
|
||||
from the current situation. Specifically, the artifact master and
|
||||
signing subkeys (and revocation certificate too) need to be
|
||||
safeguarded closely as they provide guarantees against post-release
|
||||
tampering. Our existing secret management solutions should be
|
||||
sufficient for this purpose. The signing subkey is the only one
|
||||
exposed to a separate server (signing.slave.openstack.org), and the
|
||||
Jenkins master to which this is registered is theoretically
|
||||
vulnerable to attack from its other Jenkins slaves. Switching away
|
||||
from Jenkins or upgrading to a release which supports `slave to
|
||||
master access control
|
||||
<https://wiki.jenkins-ci.org/display/JENKINS/Slave+To+Master+Access+Control>`_
|
||||
may be warranted to mitigate this risk.
|
||||
|
||||
Note that this spec does not attempt to address trust challenges
|
||||
earlier in the development, test and build toolchain. There are
|
||||
strengthening opportunities throughout our infrastructure, but they
|
||||
are out of scope and should be handled as separate specifications.
|
||||
|
||||
Testing
|
||||
-------
|
||||
|
||||
One or more artifact signing jobs will need to be created to
|
||||
generate and upload detached signatures to tarballs.openstack.org.
|
||||
There are also opportunities here to add some additional validation
|
||||
in our jobs which upload to external repositories, as they can
|
||||
potentially validate the detached signatures and refuse to upload if
|
||||
something looks wrong.
|
||||
|
||||
Dependencies
|
||||
============
|
||||
|
||||
There are no dependencies for this specification.
|
||||
Loading…
Reference in New Issue