From d5a46f025cadb9272c0f0b692fac2e12b1183adc Mon Sep 17 00:00:00 2001 From: Jeremy Stanley Date: Fri, 14 Aug 2015 18:28:25 +0000 Subject: [PATCH] Artifact Signing Toolchain The OpenStack Community will publish cryptographic signatures accompanying release artifacts (tarballs, packages, et cetera) to provide a verification of provenance. Change-Id: I9835a6aff0c67c8664b94b12fc718b8a1456ceb9 --- doc/source/index.rst | 1 + specs/artifact-signing.rst | 175 +++++++++++++++++++++++++++++++++++++ 2 files changed, 176 insertions(+) create mode 100644 specs/artifact-signing.rst diff --git a/doc/source/index.rst b/doc/source/index.rst index 583f6e4..5ceff0c 100644 --- a/doc/source/index.rst +++ b/doc/source/index.rst @@ -35,6 +35,7 @@ permits. :maxdepth: 1 specs/ansible_puppet_apply + specs/artifact-signing specs/centralize-release-tagging specs/code-search specs/doc-publishing diff --git a/specs/artifact-signing.rst b/specs/artifact-signing.rst new file mode 100644 index 0000000..b105401 --- /dev/null +++ b/specs/artifact-signing.rst @@ -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 +`_ +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.