centersl/docker-docs
1
0
Fork 0
mirror of https://github.com/docker/docs.git synced 2026-04-05 18:58:55 +07:00
Code Issues Packages Projects Releases Wiki Activity

Merge pull request #685 from docker/docs-update

Browse Source 
Update doc diagrams
This commit is contained in:
David Lawrence
2016-04-19 13:49:03 -07:00
parent a840012e88 5576e01649
commit 4c52b3801f
5 changed files with 442 additions and 21 deletions
Download Patch File Download Diff File Expand all files Collapse all files

336
docs/images/metadata-sequence.svg
View File

File diff suppressed because one or more lines are too long
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 43 KiB

After

Width:  |  Height:  |  Size: 36 KiB

93
docs/images/service-architecture.svg
View File

File diff suppressed because one or more lines are too long
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 26 KiB

After

Width:  |  Height:  |  Size: 22 KiB

2
docs/images/service-deployment.svg
View File

File diff suppressed because one or more lines are too long
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 31 KiB

After

Width:  |  Height:  |  Size: 32 KiB

2
docs/running_a_service.md
View File

@@ -225,7 +225,7 @@ independently. The database may also be scaled independently but this is left as
and exercise for experienced DBAs and Operations teams. A typical deployment will
look like the below diagram:
![Notary server Deployment Diagram](images/service-deployment.svg)
![Notary server Deployment Diagram](https://cdn.rawgit.com/docker/notary/09f81717080f53276e6881ece57cbbbf91b8e2a7/docs/images/service-deployment.svg)
In the diagram, a load balancer routes external traffic to a cluster of Notary server
instances. These may make requests to Notary signer instances if either a) signing

30
docs/service_architecture.md
View File

@@ -20,7 +20,7 @@ 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>
<center><img src="https://cdn.rawgit.com/docker/notary/09f81717080f53276e6881ece57cbbbf91b8e2a7/docs/images/key-hierarchy.svg" alt="TUF Key Hierarchy" width="400px"/></center>
- The root key is the root of all trust. It signs the
<a href="https://github.com/theupdateframework/tuf/blob/1bed3e09a478c2c918ffbff10b9118f6e52ee129/docs/tuf-spec.txt#L489" target="_blank">root metadata file</a>,
@@ -77,7 +77,7 @@ for multiple trusted collections in an associated database, and a Notary signer,
stores private keys for and signs metadata for the Notary server. The following
diagram illustrates this architecture:
![Notary Service Architecture Diagram](images/service-architecture.svg)
![Notary Service Architecture Diagram](https://cdn.rawgit.com/docker/notary/09f81717080f53276e6881ece57cbbbf91b8e2a7/docs/images/service-architecture.svg)
Root, targets, and (sometimes) snapshot metadata are generated and signed by
clients, who upload the metadata to the Notary server. The server is
@@ -101,20 +101,20 @@ The Notary signer is responsible for:
The following diagram illustrates the interactions between the Notary client,
server, and signer:
![Notary Service Sequence Diagram](images/metadata-sequence.svg)
![Notary Service Sequence Diagram](https://cdn.rawgit.com/docker/notary/09f81717080f53276e6881ece57cbbbf91b8e2a7/docs/images/metadata-sequence.svg)
1. Notary server optionally supports authentication from clients using
<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.
If token authentication is enabled on Notary server, then any connecting
client that does not have a token will be redirected to the authorization
server.
If token authentication is enabled on Notary server, then any connecting
client that does not have a token will be redirected to the authorization
server.
Please see the docs for [Docker Registry v2 authentication](
https://github.com/docker/distribution/blob/master/docs/spec/auth/token.md)
for more information.
Please see the docs for [Docker Registry v2 authentication](
https://github.com/docker/distribution/blob/master/docs/spec/auth/token.md)
for more information.
2. The client will log in to the authorization server via basic auth over HTTPS,
obtain a bearer token, and then present the token to Notary server on future
@@ -137,17 +137,17 @@ server, and signer:
database. The generated timestamp and snapshot metadata certify that the
metadata files the client uploaded are the most recent for that trusted collection.
Finally, Notary server will notify the client that their upload was successful.
Finally, Notary server will notify the client that their upload was successful.
7. The client can now immediately download the latest metadata from the server,
using the still-valid bearer token to connect. Notary server only needs to
obtain the metadata from the database, since none of the metadata has expired.
In the case that the timestamp has expired, Notary server would go through
the entire sequence where it generates a new timestamp, request Notary signer
for a signature, stores the newly signed timestamp in the database. It then
sends this new timestamp, along with the rest of the stored metadata, to the
requesting client.
In the case that the timestamp has expired, Notary server would go through
the entire sequence where it generates a new timestamp, request Notary signer
for a signature, stores the newly signed timestamp in the database. It then
sends this new timestamp, along with the rest of the stored metadata, to the
requesting client.
## Threat model