mirror of https://github.com/docker/docs.git
Turn external links into html tags that target a new window.
Make the links to www.theupdateframework.com consistent. Link to a particular git sha of the TUF spec. Signed-off-by: Ying Li <ying.li@docker.com>
This commit is contained in:
Ying Li
parent
ac213d44c8
commit
7cbe4da88f
|
|
@ -22,7 +22,7 @@ received content.
|
|||
|
||||
## Goals
|
||||
|
||||
Notary is based on [The Update Framework](http://theupdateframework.com/), a secure general design for the problem of software distribution and updates. By using TUF, notary achieves a number of key advantages:
|
||||
Notary is based on [The Update Framework](https://www.theupdateframework.com/), a secure general design for the problem of software distribution and updates. By using TUF, notary achieves a number of key advantages:
|
||||
|
||||
* **Survivable Key Compromise**: Content publishers must manage keys in order to sign their content. Signing keys may be compromised or lost so systems must be designed in order to be flexible and recoverable in the case of key compromise. TUF's notion of key roles is utilized to separate responsibilities across a hierarchy of keys such that loss of any particular key (except the root role) by itself is not fatal to the security of the system.
|
||||
* **Freshness Guarantees**: Replay attacks are a common problem in designing secure systems, where previously valid payloads are replayed to trick another system. The same problem exists in the software update systems, where old signed can be presented as the most recent. notary makes use of timestamping on publishing so that consumers can know that they are receiving the most up to date content. This is particularly important when dealing with software update where old vulnerable versions could be used to attack users.
|
||||
|
|
|
|||
|
|
@ -102,14 +102,16 @@ The targets key must be locally managed - to rotate the targets key, for instanc
|
|||
|
||||
### Use a Yubikey
|
||||
|
||||
Notary can be used with [Yubikey
|
||||
4](https://www.yubico.com/products/yubikey-hardware/yubikey4/) keys, via a PKCS11 interface when the Yubikey has CCID mode enabled.
|
||||
Notary can be used with
|
||||
<a href="https://www.yubico.com/products/yubikey-hardware/yubikey4/" target="_blank">Yubikey
|
||||
4</a> keys, via a PKCS11 interface when the Yubikey has CCID mode enabled.
|
||||
The Yubikey will be prioritized to store root keys, and will require user touch-input for signing.
|
||||
|
||||
>**Note**: Yubikey support for signing docker images is only supported in the experimental branch.
|
||||
|
||||
Yubikey support requires [Yubico PIV libraries (which are bundled with the PIV
|
||||
tools)](https://www.yubico.com/support/downloads) to be available in standard
|
||||
Yubikey support requires
|
||||
<a href="https://www.yubico.com/support/downloads" target="_blank">Yubico PIV libraries
|
||||
(which are bundled with the PIV tools)</a> to be available in standard
|
||||
library locations.
|
||||
|
||||
## Work with delegation roles
|
||||
|
|
|
|||
|
|
@ -13,16 +13,20 @@ weight=99
|
|||
|
||||
## v0.2
|
||||
#### 2/24/2016
|
||||
Adds support for [delegation roles](https://github.com/theupdateframework/tuf/blob/develop/docs/tuf-spec.txt#L387) in TUF.
|
||||
Adds support for
|
||||
<a href="https://github.com/theupdateframework/tuf/blob/1bed3e09a478c2c918ffbff10b9118f6e52ee129/docs/tuf-spec.txt#L387" target="_blank">delegation
|
||||
roles</a> in TUF.
|
||||
Delegations allow for easier key management amongst collaborators in a notary trusted collection, and fine-grained permissions on what content each delegate is allowed to modify and sign.
|
||||
This version also supports managing the snapshot key on notary server, which should be used when enabling delegations on a trusted collection.
|
||||
Moreover, this version also adds more key management functionality to the notary CLI, and changes the docker-compose development configuration to use the official MariaDB image.
|
||||
|
||||
> Detailed release notes can be found here: [v0.2 release notes](https://github.com/docker/notary/releases/tag/v0.2.0).
|
||||
> Detailed release notes can be found here:
|
||||
<a href="https://github.com/docker/notary/releases/tag/v0.2.0" target="_blank">v0.2 release notes</a>.
|
||||
|
||||
## v0.1
|
||||
#### 11/15/2015
|
||||
Initial notary non-alpha release.
|
||||
Implements The Update Framework (TUF) with root, targets, snapshot, and timestamp roles to sign and verify content of a trusted collection.
|
||||
|
||||
> Detailed release notes can be found here: [v0.1 release notes](https://github.com/docker/notary/releases/tag/v0.1).
|
||||
> Detailed release notes can be found here:
|
||||
<a href="https://github.com/docker/notary/releases/tag/v0.1" target="_blank">v0.1 release notes</a>.
|
||||
|
|
|
|||
|
|
@ -24,16 +24,17 @@ and origin of content. This ability is built on a straightforward key management
|
|||
and signing interface to create signed collections and configure trusted publishers.
|
||||
|
||||
With Notary anyone can provide trust over arbitrary collections of data. Using
|
||||
[The Update Framework (TUF)](http://theupdateframework.com/) as the underlying
|
||||
security framework, Notary takes care of the operations necessary to create, manage
|
||||
and distribute the metadata necessary to ensure the integrity and freshness of
|
||||
your content.
|
||||
<a href="https://www.theupdateframework.com/" target="_blank">The Update Framework (TUF)</a>
|
||||
as the underlying security framework, Notary takes care of the operations necessary
|
||||
to create, manage and distribute the metadata necessary to ensure the integrity and
|
||||
freshness of your content.
|
||||
|
||||
## Install Notary
|
||||
|
||||
You can download precompiled notary binary for 64 bit Linux or Mac OS X from the
|
||||
Notary repository's [releases page on
|
||||
GitHub](https://github.com/docker/notary/releases). Windows is not officially
|
||||
Notary repository's
|
||||
<a href="https://github.com/docker/notary/releases" target="_blank">releases page on
|
||||
GitHub</a>. Windows is not officially
|
||||
supported, but if you are a developer and Windows user, we would appreciate any
|
||||
insight you can provide regarding issues.
|
||||
|
||||
|
|
|
|||
|
|
@ -54,9 +54,9 @@ below to configure it.
|
|||
|
||||
The reporting section contains any configuration for useful for running the
|
||||
service, such as reporting errors. Currently, Notary only supports reporting errors
|
||||
to [Bugsnag](https://bugsnag.com).
|
||||
to <a href="https://bugsnag.com" target="_blank">Bugsnag</a>.
|
||||
|
||||
See [bugsnag-go](https://github.com/bugsnag/bugsnag-go/) for more information
|
||||
See <a href="https://github.com/bugsnag/bugsnag-go/" target="_blank">bugsnag-go</a> for more information
|
||||
about these configuration parameters.
|
||||
|
||||
```json
|
||||
|
|
|
|||
|
|
@ -267,7 +267,7 @@ configure it.
|
|||
**Token authentication:**
|
||||
|
||||
This is an implementation of the same authentication used by version 2 of the
|
||||
[Docker registry](https://github.com/docker/distribution). (JWT token-based
|
||||
<a href="https://github.com/docker/distribution" target="_blank">Docker registry</a>. (JWT token-based
|
||||
authentication post login.)
|
||||
|
||||
<table>
|
||||
|
|
|
|||
|
|
@ -21,7 +21,7 @@ and [Docker Compose](https://docs.docker.com/compose/overview/).
|
|||
|
||||
The quickest way to spin up a full Notary service for testing and development
|
||||
purposes is to use the Docker compose file in the
|
||||
[Notary project](https://github.com/docker/notary).
|
||||
<a href="https://github.com/docker/notary" target="_blank">Notary project</a>.
|
||||
|
||||
```plain
|
||||
$ git clone https://github.com/docker/notary.git
|
||||
|
|
@ -75,9 +75,9 @@ the following command line arguments:
|
|||
- `-config=<config file>` - specify the path to the JSON configuration file.
|
||||
|
||||
- `-debug` - Passing this flag enables the debugging server on `localhost:8080`.
|
||||
The debugging server provides [pprof](https://golang.org/pkg/net/http/pprof/)
|
||||
and [expvar](https://golang.org/pkg/expvar/) endpoints. (Remember, this
|
||||
is localhost with respect to the running container - this endpoint is not
|
||||
The debugging server provides <a href="https://golang.org/pkg/net/http/pprof/" target="_blank">pprof</a>
|
||||
and <a href="https://golang.org/pkg/expvar/" target="_blank">expvar</a> endpoints.
|
||||
(Remember, this is localhost with respect to the running container - this endpoint is not
|
||||
exposed from the container).
|
||||
|
||||
This option can also be set in the configuration file.
|
||||
|
|
|
|||
|
|
@ -16,20 +16,21 @@ On this page, you get an overview of the Notary service architecture.
|
|||
|
||||
## Brief overview of TUF keys and roles
|
||||
|
||||
This document assumes familiarity with [The Update Framework](https://theupdateframework.github.io/),
|
||||
This document assumes familiarity with
|
||||
<a href="https://www.theupdateframework.com/" target="_blank">The Update Framework</a>,
|
||||
but here is a brief recap of the TUF roles and corresponding key hierarchy:
|
||||
|
||||
<center><img src="images/key-hierarchy.svg" alt="TUF Key Hierarchy" width="400px"/></center>
|
||||
|
||||
- The root key is the root of all trust. It signs the
|
||||
[root metadata file](https://github.com/theupdateframework/tuf/blob/develop/docs/tuf-spec.txt#L489),
|
||||
<a href="https://github.com/theupdateframework/tuf/blob/1bed3e09a478c2c918ffbff10b9118f6e52ee129/docs/tuf-spec.txt#L489" target="_blank">root metadata file</a>,
|
||||
which lists the IDs of the root, targets, snapshot, and timestamp public keys.
|
||||
Clients use these public keys to verify the signatures on all the metadata files
|
||||
in the repository. This key is held by a collection owner, and should be kept offline
|
||||
and safe, more so than any other key.
|
||||
|
||||
- The snapshot key signs the
|
||||
[snapshot metadata file](https://github.com/theupdateframework/tuf/blob/develop/docs/tuf-spec.txt#L604),
|
||||
<a href="https://github.com/theupdateframework/tuf/blob/1bed3e09a478c2c918ffbff10b9118f6e52ee129/docs/tuf-spec.txt#L604" target="_blank">snapshot metadata file</a>,
|
||||
which enumerates the filenames, sizes, and hashes of the root,
|
||||
targets, and delegation metadata files for the collection. This file is used to
|
||||
verify the integrity of the other metadata files. The snapshot key is held by
|
||||
|
|
@ -37,7 +38,7 @@ either a collection owner/administrator, or held by the Notary service to facili
|
|||
[signing by multiple collaborators via delegation roles](advanced_usage#working-with-delegation-roles).
|
||||
|
||||
- The timestamp key signs the
|
||||
[timestamp metadata file](https://github.com/theupdateframework/tuf/blob/develop/docs/tuf-spec.txt#L827),
|
||||
<a href="https://github.com/theupdateframework/tuf/blob/1bed3e09a478c2c918ffbff10b9118f6e52ee129/docs/tuf-spec.txt#L827" target="_blank">timestamp metadata file</a>,
|
||||
which provides freshness guarantees for the collection by having the shortest expiry time of any particular
|
||||
piece of metadata and by specifying the filename, size, and hash of the most recent
|
||||
snapshot for the collection. It is used to verify the integrity of the snapshot
|
||||
|
|
@ -46,18 +47,18 @@ automatically re-generated when it is requested from the server, rather than
|
|||
require that a collection owner come online before each timestamp expiry.
|
||||
|
||||
- The targets key signs the
|
||||
[targets metdata file](https://github.com/theupdateframework/tuf/blob/develop/docs/tuf-spec.txt#L678),
|
||||
<a href="https://github.com/theupdateframework/tuf/blob/1bed3e09a478c2c918ffbff10b9118f6e52ee129/docs/tuf-spec.txt#L678" target="_blank">targets metdata file</a>,
|
||||
which lists filenames in the collection, and their sizes and respective
|
||||
[hashes](https://en.wikipedia.org/wiki/Cryptographic_hash_function).
|
||||
<a href="https://en.wikipedia.org/wiki/Cryptographic_hash_function" target="_blank">hashes</a>.
|
||||
This file is used to verify the integrity of some or all of the actual contents of the repository.
|
||||
It is also used to
|
||||
[delegate trust to other collaborators via delegation roles](advanced_usage#working-with-delegation-roles).
|
||||
The targets key is held by the collection owner or administrator.
|
||||
|
||||
- Delegation keys sign
|
||||
[delegation metdata files](https://github.com/theupdateframework/tuf/blob/develop/docs/tuf-spec.txt#L678),
|
||||
<a href="https://github.com/theupdateframework/tuf/blob/1bed3e09a478c2c918ffbff10b9118f6e52ee129/docs/tuf-spec.txt#L678" target="_blank">delegation metdata files</a>,
|
||||
which lists filenames in the collection, and their sizes and respective
|
||||
[hashes](https://en.wikipedia.org/wiki/Cryptographic_hash_function).
|
||||
<a href="https://en.wikipedia.org/wiki/Cryptographic_hash_function" target="_blank">hashes</a>.
|
||||
These files is used to verify the integrity of some or all of the actual contents of the repository.
|
||||
They are is also used to
|
||||
[delegate trust to other collaborators via lower level delegation roles](advanced_usage#working-with-delegation-roles).
|
||||
|
|
@ -70,8 +71,8 @@ Notary clients pull metadata from one or more (remote) Notary services. Some
|
|||
Notary clients will push metadata to one or more Notary services.
|
||||
|
||||
A Notary service consists of a Notary server, which stores and updates the
|
||||
signed [TUF metadata files](
|
||||
https://github.com/theupdateframework/tuf/blob/develop/docs/tuf-spec.txt#L348)
|
||||
signed
|
||||
<a href="https://github.com/theupdateframework/tuf/blob/1bed3e09a478c2c918ffbff10b9118f6e52ee129/docs/tuf-spec.txt#L348">TUF metadata files</a>
|
||||
for multiple trusted collections in an associated database, and a Notary signer, which
|
||||
stores private keys for and signs metadata for the Notary server. The following
|
||||
diagram illustrates this architecture:
|
||||
|
|
@ -89,12 +90,9 @@ responsible for:
|
|||
The Notary signer is responsible for:
|
||||
|
||||
- storing the private signing keys
|
||||
[wrapped](
|
||||
https://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-31#section-4.4)
|
||||
and [encrypted](
|
||||
https://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-31#section-4.8)
|
||||
using [Javascript Object Signing and Encryption](
|
||||
https://github.com/dvsekhvalnov/jose2go) in a database separate from the
|
||||
<a href="https://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-31#section-4.4" target="_blank">wrapped</a>
|
||||
and <a href="https://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-31#section-4.8" target="_blank">encrypted</a>
|
||||
using <a href="https://github.com/dvsekhvalnov/jose2go" target="_blank">Javascript Object Signing and Encryption</a> in a database separate from the
|
||||
Notary server database
|
||||
- performing signing operations with these keys whenever the Notary server requests
|
||||
|
||||
|
|
@ -106,7 +104,7 @@ sever, and signer:
|
|||
|
||||
|
||||
1. Notary server optionally supports authentication from clients using
|
||||
[JWT](http://jwt.io/) tokens. This requires an authorization server that
|
||||
<a href="http://jwt.io/" target="_blank">JWT</a> tokens. This requires an authorization server that
|
||||
manages access controls, and a cert bundle from this authorization server
|
||||
containing the public key it uses to sign tokens.
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue