Code Monkey home page Code Monkey logo

dct-notary-admin's Introduction

Docker Content Trust - Notary Admin

Continuous Integration codecov

This API and webapp add the capability to manage your Docker Content Trust and notary certificates.

It allows you to create new Target certificates for your Docker repositories, as well authorizing delegates for the repository.

This way the certificates can be stored in a secured environment where backups are managed.

This project makes use of a Notary sandbox which is an in progress development setup, which is intended to be contributed upstream. The Fork is by no means a hard Fork of Notary and is solely there to bridge a period of time to get this back in the upstream.

API endpoints

HTTP Method URL description
GET https://localhost:8443/ping return pong
GET https://localhost:8443/targets retrieves all target keys
POST https://localhost:8443/targets creates a new target and keys
GET https://localhost:8443/targets/{id} retrieves a single target key
GET https://localhost:8443/targets/{id}/delegations retrieves all delegate keys for a given target
POST https://localhost:8443/targets/{id}/delegations add a new delegation to the given target
DELETE https://localhost:8443/targets/{id}/delegations/{delegation} remove a delegation from the given target

Prerequisites

For a easier development workflow it is recommended to install CMake. To interact with Hashicorp Vault the vault cli is convenient.

platform install url
Windows choco install -y cmake cmake-3.16.2-win64-x64.msi
MacOSX brew install cmake cmake-3.16.2-Darwin-x86_64.dmg
Windows choco install -y vault vault_1.4.2_windows_amd64.zip
MacOSX brew install vault vault_1.4.2_darwin_amd64.zip

Accept Self signed certs in Google Chrome

For Google Chrome to accept the selfsigned certificates please enable the option allow-insecure-localhost by navigating to in your address bar.

To only allow for the current certificate that is blocked type thisisunsafe with focus on the Your connection is not private page, the page will autorefresh once the full phrase is typed. In older versions of chrome you had to type badidea or danger.

Run the sandbox

To run in an isolated environment to do some testing you should run the sandbox. The sandbox connects to a notary server and registry in the docker-compose setup.

Initializing the notary git submodule.

git submodule update --init --recursive

Build the sandbox

make build-sandbox

Run the sandbox

make run-sandbox

To provision the notary sandbox with some signed images you can use the bootstrap-sandbox make target (optional).

make bootstrap-sandbox

To play with the notary and docker trust cli you can open the shell for the sandbox. Signing docker images using docker content trust

docker-compose -f notary/docker-compose.sandbox.yml -f docker-compose.yml exec sandbox sh

To shutdown the sandbox you can run the stop-sandbox make target.

make stop-sandbox

Run vault development server

To boot the Hashicorp Vault development server run the following. Requires vault installed, (e.g. brew install vault).

docker-compose -f vault/docker-compose.dev.yml up -d
vault/prepare.sh dev

prepare.sh boots vault server and provisions the secret engine with required policies, secret engines etc.

The vault admin dashboard is available at http://localhost:8200.

The token can be found in the server logs.

docker-compose -f vault/docker-compose.dev.yml logs | grep "Root Token"

Build binary (api)

make build

Test

To run the tests, make sure to run make stop-sandbox first (tests are also reusing the same sandbox which require a clean env).

make test

Run the tests with coverage.

make coverage-out

Check the coverage report in your browser.

make coverage-html

Run

The API utilizes Hashicorp vault to generate and store passwords for private keys. The endpoint to Hashicorp vault can be configured via the environment variable VAULT_ADDR or as a commandline flag. The default value points to http://localhost:8200 (the address of the development server).

API Server

Now you can start the API server as following:

# environment variable
export VAULT_ADDR=http://localhost:8200
bin/dctna-server --config .notary/config.json

Alternatively you provide the vault server address as parameter.

# commandline option
bin/dctna-server --vault-addr http://localhost:8200 --config .notary/config.json

NOTE: you can pass the sandbox .notary/config.json as above, without this setting the default notary folder will be used ($USER/.natary/config.json).

Or via the Make shorthand which also builds the solution, which will use the sandbox config for notary.

make run

NOTE: via make we will also use our sandboxed .notary/config.json automatically to prevent you from messing arround with your current notary (Production) settings.

Web Frontend

cd web
yarn install && yarn start

Testing end to end

Now you can create new targets for signing docker images http://localhost:3000 using the webinterface.

E.g.:

  • Target: localhost:5000/nginx
  • Target: localhost:5000/stuff

Then on one of the targets we will authorize our personal delegation key. If you don't have one yet you can generate it via the docker trust cli.

docker trust key generate johndoe --dir ~/.docker/trust

Then simply copy the contents of the public key to your clipboard.

cat ~/.docker/trust/johndoe.pub | pbcopy

In the webinterface you can now add your delegation on the target localhost:5000/nginx.

name key
john_doe paste_clipboard_contents

Now to be able to sign an image all signing keys have to be available on your local system. In Notary v2 this will be improved to also be able to work with remote signing keys. You will only need the passphrase for your delegation key.

This will now allow us to sign docker images for localhost:5000/nginx. In below example we first pull an image from the public registry. Then tag it to push to our sandbox registry. Then we enable content trust and configure our sandbox notary endpoint. Upon pushing to the repository you will be prompted for the password of your signing delegation key. Please note if you haven't added your delegation key in dctna, you will not be able to sign.

docker pull nginx:alpine
docker tag nginx:alpine localhost:5000/nginx:alpine
export DOCKER_CONTENT_TRUST=1 DOCKER_CONTENT_TRUST_SERVER=https://localhost:4443
docker push localhost:5000/nginx:alpine

dct-notary-admin's People

Contributors

brend-smits avatar dependabot[bot] avatar marcofranssen avatar npalm avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar

Forkers

syllogy

dct-notary-admin's Issues

Add capability for easy distributing signing keys and credentials to CI/CD

The docker trust client needs all the certificates in the tree to be able to sign an image. (notary v2 is resolving the issue of having some certificates remote)
This doesn't mean the client also needs the credentials for those keys as long there is a delegation available for this repository.

For CI/CD processes it should be easy to retrieve the keys required for a given repository using e.g. a simple curl request or a small cli tool which puts the keys in the right place.

The credential for a CI jobs delegation key can be retrieved from vault or could also be integrated in this small tool. Once the credential is retrieved, the CI/CD process can set the following environment variable to make the process non interactive.

DOCKER_CONTENT_TRUST_REPOSITORY_PASSPHRASE

without that env variable set you will be prompted to enter the password for the delegation key or the repository key. For CI/CD it is important this will be set automagically.

Enhance integration testing for notary server preseeding

To have better repeatable tests we need to have a script to prepare the notary-server in the docker sandbox using data that is a aligned with the .notary folder in this repository.

The .notary folder commited contains a local cache of the certificates created and published on the server. Once the timestamp keys expire the tests will now fail, because every server reboot we will loose the notary server data.

Before running the tests we need to run some kind of preseed script that publishes the local data on notary server to have a good initial test setup.

Alternative

We need to modify the tests in some way to not be dependant on this data and use some newly generated certificates to operate the tests.

Or

We need to see how we can make the tests using mocking or in memory kind of approach so we don't depend on the sandbox for this.

Implement endpoint to initialize a new repo

https://github.com/docker/cli/blob/ae1618713f83e7da07317d579d0675f578de22fa/cli/command/trust/helpers.go#L41

notary init docker.io/philipssoftware/test
initializes a repo which is compatible with docker trust

E.g.:

$ notary init docker.io/marcofranssen/test
$ notary list docker.io/marcofranssen/test               

No targets present in this repository.
$ docker trust inspect marcofranssen/test --pretty

No signatures for marcofranssen/test


Administrative keys for marcofranssen/test

  Repository Key:       0bac4a4d1aa01ef8825e44ef27ad8e3dc333bc0856c55ded414f942c0f902beb
  Root Key:     e220d072f747ec4a340bd94fc2542f2ab982554e24560668e68dd39044923bdc

Configmap for docker registry and notary server to be used.

To be able to run the admin interface for multiple registries with their own notary sidecars or shared sidecars it should be possible to define a map of registry and related notary server.

e.g.

repos starting with docker.io should use notary.docker.io
repos starting with myregistry.com should use notary.internal.company.com
etc.

This also means more advanced authentication mechanism needs to be put in place #48.

Add web interface for adding new delegation key

The form should allow for uploading or copy pasting the public key to be added as a delegation for the given target.

POST /api/targets/ab234bc/delegations

where ab234bc is the id of a target.

Add API endpoint to revoke delegate key for existing target

Revocation should can only be done if the latest signed image tags are not signed by this key.

Minimum viable:

  • return a HTTP error response to inform API consumer there are images signed with this key

Improvement:

  • which tags are signed with this key

GitHub Actions is deprecating `set-env` and `add-path` commands.

GitHub Actions is deprecating set-env and add-path commands. Check out this blog post for more details.

This repository has been listed by a scan that it uses one of de deprecated actions. It could be case the commands are directly usages in the build yaml, or indirect via an action. Action runners above version 2.273.5 will warn for usages of these deprecated commands. Expectation is that the commands will be disabled before the end of the year.

Please check your build YAML and action log to ensure your build keep working once the commands are disabled.

Feel free to reach out if you question or any help is needed

Regards, Niek Palm (@npalm)

this issue is generated based on a scan

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.