►
From YouTube: Introduction to Notary - Justin Cormack, Docker
Description
Join us for Kubernetes Forums Seoul, Sydney, Bengaluru and Delhi - learn more at kubecon.io
Don't miss KubeCon + CloudNativeCon 2020 events in Amsterdam March 30 - April 2, Shanghai July 28-30 and Boston November 17-20! Learn more at kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects
Introduction to Notary - Justin Cormack, Docker
This talk introduces the Notary project, an implementation of The Update Framework for container applications. This is the major project for container image signing, and is used by Docker Hub, Azure Container Registry, Harbor and others. This talk will give an overview of how Notary works, how to use it and integrate it with other projects, ongoing work on the project, and how to contribute.
https://sched.co/XC8C
A
Okay,
so
before
I
get
started
here,
just
a
little
show
of
hands
who,
in
this
conference,
has
already
attended
a
tough
or
docker
talk.
Okay,
great
I'm,
glad
I,
don't
see
all
of
your
hands
so
who
so
I'm
just
in
Cormac
no
I'm,
not
okay,
so
just
curious.
Just
in
Cormac,
apparently,
something
happened
at
docker
and
Justin.
Cormac
was
right
there.
He
saw
the
signal
and
he
had
to
run
off
so
I'm
gonna
be
doing
my
Justin
Cormac
impression,
so
to
do
that.
I'm
gonna,
put
on
my
docker
con
speaker,
dr.
A
Khan
19
speaker
hoodie,
to
try
to
get
me
into
the
mood
here
and
I
apologized
a
little
bit
for
this.
For
those
few
of
you
who
have
been
to
a
previous
talk,
because
since
I
am
Justin
kapos
professor
at
NYU,
who
you
know
creator
of
the
tough
project,
I'm
gonna
be
giving
this
talk
along
with
a
PhD
student
of
mine,
Santiago
Torres
is
right.
There
who's
also
at
NYU
we're
going
to
be
focusing
a
bit
more
on
tough.
A
Although
we
will
talk
a
lot
about
notary
at
the
end
and
Santiago
is
going
to
do
a
great
demo
for
us,
so
let
me
go
ahead
and
get
us
started.
So
what
tough
and
notary
and
other
you
know
like
the
goal
of
them,
the
thing
that
they
try
to
prove
it
protect
against.
Is
they
try
to
protect
against
a
very
specific
attack,
vector
it's
an
attack
vector
that
is
used
by
some
of
the
best
hackers
around
the
world?
It
bypasses
any
scanning
and
security
systems
that
you
have
in
place.
A
So
if
you
have
a
firewall
or
an
IDs
or
other
things
like
that,
it's
ineffective
it's
on
basically,
every
device
that
you
can
imagine
every
type
of
thing
you
can
think
about
whether
it's
a
car
or
refrigerator
an
Xbox.
Whatever
else
this
attack
vector
is
there
and
it's
also
been
used
to
just
amazingly
damaging
effect
by
the
best
hackers
in
the
world
when
nation
state
actors
want
to
go
and
hack
into
things,
they
use
the
specter
over
and
over
and
over
again,
and
also
it's
something
that
has
hit
many
many
many
victims.
A
A
I've
now
protected
my
bike
right,
but
how
you
apply
that
crypto
and
what
you
do
really
matters,
and
so,
let's
look
at
why
a
simple
application
of
crypto
is
the
reason
why
a
lot
of
the
companies
on
the
slide
before
this
ended
up
on
that
slide.
You
know
why
their
users
why
they
had
problems,
why
they
get
hacked.
So
let's
just
say
that
you
go,
you
know
you
have
a
setup
where
your
server
has
x.509
certificate,
and
this
is
trusted
by
your
clients.
A
So
your
clients
want
to
go
and
update,
and
your
server
has
the
little
Silver
Star
here
saying
it
is
the
trusted
party,
so
your
clients
will
go
and
then
try
to
retrieve
content.
Well,
all
that
that
you
know
all
that
that
x.509,
certain
the
private
key
and
so
on
is
telling
you
is
telling
you
you
are
talking
to
the
server.
It's
not
telling
you
that
what
the
server
is
giving.
You
is
a
trustworthy,
valid
thing
it
just
authenticates
who
your
can
be
kidding
with.
A
So
if
the
server
gets
hacked,
then
any
of
the
clients
can
be
given
anything
by
that
server
and,
of
course,
because
you're
running
something
like
a
web
server
with
full
OS
stack,
and
you
know
a
bunch
of
other
stuff
on
there.
It's
it's
complicated
and
hacks
happen
time
and
time
and
time
and
time
again,
all
right.
So
the
other
approach
that
gets
they
got
the
other
half
of
the
companies
on
that
slide
is
to
do
something
where
you
have
a
separate
signing
key.
A
So
this
is
something
like
you
know,
maybe
use
like
an
RSA
key
or
GPG
key
or
something
like
that.
Where
now
you
go
and
you
have
a
bunch
of
developers
and
the
developers
one
way
of
setting
this
up
is
the
developers
are
all
sort
of
trusted
like
you
can
imagine
something
like
you
know,
a
keyring
for
something
like
Debian,
where
you've
got
hundreds
of
developers
that
have
their
keys
listed
and
then
any
one
of
the
developers
gets
hacked.
A
Maybe
that's
the
developer
that
all
they
do
is
update
the
you
know
the
Polish
language,
translation
for
a
certain
piece
of
documentation,
but
their
keys
on
the
key
ring,
because
they
need
to
do
that,
then
they
can
go
and
push
updates
to
the
to
the
kernel
or
whatever
other
packages
they
want
and
boom.
You
have
a
big
problem.
A
The
other
way
that
organizations
do
this
using
something
like
RSA
or
GPG,
or
even
something
like
an
HSM,
is
they
go
and
they
have
a
system
in
their
infrastructure
like
a
build
like
a
build
server
or
something
else,
and
that
build
server
has
a
key
on
it
and
then,
of
course,
what
happens
and
and
has
happened
with
a
lot
of
companies
like
Red,
Hat
and
others
is
then
someone
goes
that
and
breaks
into
that
build
system
and
then
boom.
They
do
it.
A
So
in
all
these
cases,
you
sort
of
have
this
problem
where
you
know,
if
you
apply
your
crypto
in
not
quite
the
right
way,
you
end
up
getting
your
name
on
my
slide
of
shame
in
the
beginning,
all
right
so
I
think
I've
convinced
you
that
it's
not
easy
to
do
this
now,
let's
talk
about,
is
it
possible
like?
Is
there
a
solution
that
you
could
have
that
would
actually
go
and
provide
you
with
meaningful
defense
against
an
attacker?
That's
able
to
do
things
like
compromise
servers,
compromise
keys.
A
You
know
where
you
might
actually
make
a
mistake.
I
don't
know
if
anyone
has
ever
been
in
an
organization.
That's
ever
made
an
error
of
any
sort.
Yes
I'm!
Thank
you
for
all
the
laughter
from
the
audience.
I
appreciate
that
yes,
so
everyone
makes
mistakes
so
and
if
you're
going
to
possibly
make
a
mistake,
then
you
need
something
that
allows
you
to
make
mistakes
and
not
have
that
be
an
immense
security
problem
for
everyone
in
your
organization,
all
right
and
that's
really.
What
tough
is
all
about.
The
main
goal
of
tough
is
compromise
resilience.
A
The
idea
here
is
is
that,
even
if
an
even
if
you
have
a
key
lost,
some
someone
accidentally
goes
and
publishes
a
private
key
into
github
or
you
know
a
developer.
You
know
one
of
your
DevOps
people,
you
know,
starts
to
go
a
little.
You
know
crazy
and
has
to
leave
the
company,
but
you
know,
while
that
transition
is
happening,
maybe
they
try
to
cause
a
little
bit
of
panic
and
problems
on
their
way
out.
A
Tough
is
designed
to
try
to
help
so
that
you
don't
have
single
points
of
failure
or
single
problems,
and
also,
when
that
happens,
to
recover
gracefully
so
that
the
damage
that's
caused
by
an
attacker
is
minimized
and
you
can
get
back
to
a
secure
state
even
when
that
occurs.
So
in
the
example
here
with
tough,
you
would
have
a
tough
repository.
A
The
attacker
might
be
able
to
go
and
break
into
something
like
docker
hub
or
your
repo,
and
yet
your
users
are
not
at
any
substantial
risk
and
we'll
talk
a
little
bit
about
how
that
works.
But
first
I
want
to
talk
about
one
of
the
other
goals
of
tough,
which
is
to
support,
not
to
judge
so
we
know
your
infrastructure
looks
like
this,
or
at
least
parts
of
it
do
tough,
is
not
something
where
it's
not
like,
like
PCI
compliance
where
it's
a
checklist
of
things
you
have
to
do
to
meet
some
standard.
A
Tough
is
a
flexible
system
for
letting
you
go
and
have
a
sane
set
up
that
basically
matches
your
workflow
and
give
you
protection
and
security
around
that
okay,
so
you
can
keep
your
rat's
nest
and
have
it
be
better
protected
with
something
like
tough
and
and
also
do
so
in
a
way
that
doesn't
cause
you
to
you
know
to
end
up
having
a
bunch
of
operational,
additional
work
or
other
things
like
that,
as
you're
going
through
the
process
of
packaging,
your
software.
So
tough
does
this
with
four
different
properties
in
the
design
of
tough.
A
A
So
in
tough
there
are
multiple
different
keys
and-
and
there
are
parties
that
have
those
keys,
but
those
parties
will
have
different
roles
so,
for
instance,
someone
who's
a
developer
would
be
trusted
to
do
things
like
sign
a
package
that
they're
responsible
for
for
producing,
not
other
packages,
but
you
know
hey.
If
I'm
a
developer
for
the
Antonio
project,
then
I
can
sign
and
say
this
is
a
valid
release
for
in
toto,
but
that
doesn't
mean
that
I
can
go
and
sign
and
say
this
is
a
valid
spiffy.
A
You
know
spiffy
spire
release
or
something
like
that,
even
though
they
might
be
on
the
same
repository
and
also
there
are
different
roles
that
do
different
things.
For
instance,
the
repository
is
responsible
for
knowing
things
like.
Has
there
been
a
new
update,
but
it
doesn't
know
it's
not
trusted
to
tell
you.
This
is
a
valid
update,
because
there's
a
distinction
between
the
two
there's,
a
you
know.
The
developer
has
to
tell
you.
This
is
the
hash
of
the
right.
You
know
this
is
a
sign
thing
attesting.
This
is
a
right
update.
A
The
repository
just
says
there
is
a
new
update,
for
instance,
okay
and
I
kind
of
already
talked
to
that.
So
another
design
principle
and
tough
is
operationally
its
intended
to
be
something
that
you
can
meaningfully
apply
inside
your
organization
and
get
real
security.
It
you
know.
Of
course
you
could
say
we
can
make
a
perfectly
secure
system
where
every
time
anything
happens,
you
have
to
get
a
DNA
sample
from
every
person
in
the
company
to
validate
this
and
have
to
put
their
firstborn
child
in
escrow
and
dot
it
and
all
this
stuff.
A
But
it's
just
not
realistic,
like
no
one
would
ever
use
the
system
like
that
so
toughest
designed
so
that
you
can
go
and
for
the
things
that
would
be
very
sensitive
like,
for
instance,
you
know,
developer
signing
a
package.
You
can
have
something
like
a
Yubikey
that
you
have
that
you're
able
to
go
and
do
this,
which
isn't
a
big
burden
or
you
can
use
your
GPG
keys
that
maybe
you
already
use
to
sign,
get
commits,
or
whatever
else
like
that.
A
So
it's
it's
basically,
just
in
your
workflow,
you
do
the
same
normal
things
like
you
normally
are
doing,
and
in
some
cases
for
things
where
you
need
to
have
a
way
to
recover.
You
know,
like
you
know,
for
rare
events,
you
might
have
a
couple
of
keys
that
you
put
across
different
sites.
You
be
keys
and
in
desk
drawers
or
things
like
that,
but
four
keys
that
need
to
be.
You
know
online
on
something
like
the
repository.
The
impact
of
that
key
being
compromised
is
extremely
low.
A
For
a
week
before
you
realize
that
something's
fishy
has
happened
and
that's
sort
of
not
anywhere
near
as
bad
of
a
problem
as
me
being
able
to
tell
you
hey,
you
know,
no,
you
should
install
this
update.
Instead,
it
has
a
special
crypto
minor
feature
now
in
it,
okay
right.
So
if
the
impact
role
is
high
impact,
then
we
make
it
so
that
from
a
usability
standpoint,
it's
easy
to
do
things
like
keep
keys
offline
and
not
not
have
that
you
know
be
a
burdensome
thing
for
your
operators.
A
If
the
keys
have
to
be
online,
then
there's
a
small,
very
small
impact
if
a
compromise
occurs.
Another
thing
that
tough
does
is
something
that
you
know.
If
you
know,
if
you've
heard
the
old
thing
about
the
nuclear
submarines,
you
can
have
threshold
signatures
on
on
anything.
You
do
inside
of
tough.
So
you
can
say.
For
instance,
two
of
the
five
in
toto
developers
need
to
go
sign.
A
new
release,
oven
Toto
before
it's
trusted,
or
you
know,
for
our
root
Keys.
You
have
to
have
three
of
the
six
root
keys.
A
You
know
be
pulled
from
sites
around
the
world
and
do
things
and
that
way,
if
you
do
have
an
incident
where
you
have
like
Alice
and
Bob
here
that
have
their
keys
and
Alice's
ba
Alice's
key
is
compromised
or
leaked
or
whatever
else
or
Alice
goes
crazy.
Then
there's
no
risk
to
clients
in
that
case,
because
you
can
securely
revoke,
and
that
brings
us
to
the
last
point
here
which
tuff
was
designed
from
day
one
with
the
very
first.
You
know
that
the
primary
goal
is
compromised.
A
Resilience
is
to
protect
and
recover
securely
when
something
goes
wrong.
So
that
means
revocation
was
a
primary
initial
overriding
goal,
doing,
revocation
right
and
anybody
here
who
has
dealt
with
GP,
GP,
GP,
revocation
or
x.509,
revocation,
and
that
in
that
whole
domain
you
know
that
that
was
not
a
primary
first
order
thing
that
they
were
thinking
about
when
they
built
those
systems.
It's
really
really
painful
and
does
not
work
well.
Okay,
in
tough,
it's
amazingly
seamless
works
well,
and
you
can
rotate
keys
and
do
all
kinds
of
other
stuff
like
that.
A
That's
very
hard
to
do
in
other
contexts
and
there's
even
multiple
ways
where
you
can
do
this.
We
can
both
have
keys
that
you
explicitly
revoke
it's
a
very
simple.
You
know
your
operation,
the
you
do
to
delegate.
As
you
say,
I
I
want
to
go
and
I
want
to
trust
marina.
To
do
this
action
for
me
and
then
all
I
have
to
do
to
revoke.
My
trust
in
marina
is
say,
generate
the
same
file
and
just
remove
the
line
that
said.
I'd,
trust,
marina,
I
want
to
delegate
to
marina
I.
A
Remove
that
and
now
once
I
push
that
up
to
the
repository,
then
trust
in
her
has
been
revoked.
Oh
sorry,
and
you
also
have
revocation
that
that
works
based
on
time
and
delay.
I'm
gonna
skip
through
this
to
get
to
some
of
the
notary
stuff.
But
if
you
want
to
learn
more
about
the
roles
and
tough
and
how
this
all
works
together,
then
I'm
happy
to
answer
this
later
with
questions,
but
I
want
to
make
sure
that
we
get
you
to
some
of
some
of
those
aspects.
A
A
Although
the
Python
reference
implementation
is
used
in
production
by
data
dog
and
a
few
other
organizations,
Google
Amazon
and
others
have
their
own
implementations
of
tuff
that
are
used,
there's
also
an
automotive
version
of
tuff
called
obtain
that
is
part
of
automotive-grade
linux
and
is
has
multiple
major
OEMs
in
the
u.s.
in
Japan
and
in
Europe
that
have
adopted
it,
and
so
within
three
years
or
so.
A
It's
projected
that
one
third
of
new
cars
on
us
roads
will
include
obtained
as
part
of
it
obtained,
has
also
been
standardized
by
isto,
its
Aristo
I
Triple
E
isto
and
is
a
Linux
Foundation
and
JDF
project.
So
let
me
talk
really
quickly
about
the
impact
of
a
compromise
and
tough
just
to
make
this
kind
of
clear.
So
if
someone
goes
and
breaks
into
your
repository
in
Toth,
I'm
gonna
focus
the
second
column
here
just
shows:
are
they
able
to
install
malicious
updates,
because
this
is
really
the
most
important
thing?
A
I
think
you
care
about,
and
then
the
last
column
is:
can
they
recover
securely?
So
if
someone
breaks
into
your
repository,
they
can't
install
malicious
updates
and
you
can
securely
recover
from
this
instance.
If
someone
steals
a
developer
key
but
doesn't
have
a
means
to
cause
the
repository
to
accept
the
developer
commits
or
things
like
that,
then
there
also
is
no
impact.
A
Then
that
also
isn't
a
problem
if
they
do
so
Mission
Impossible,
ocean's,
11
style
heist
and
they
managed
to
get
a
threshold
of
these
all
at
once
without
anybody
noticing,
then
all
of
a
sudden,
you
start
to
have
a
problem:
okay,
but
it's
yeah,
it's
a
pretty
high
bar
and
the
you
know
so.
A
last
thing
I'd
like
to
talk
briefly
about
here
is
tough
itself,
is
a
specification
notaries,
one
implementation
of
it
and
as
part
of
being
a
specification,
we
of
course
also
have
changes
to
the
specification
that
we
take
in
from
different
communities.
A
So
we've
gone
and
integrated
a
bunch
of
changes
over
time.
We
have
even
some
changes
going
on
now,
if
you're
interested
in
participating
in
this-
and
you
have
use
cases
that
you
figure
out-
that
we
don't
handle,
then
that's
something
that
that's
how
you
end
up
being
an
author
for
some
of
the
taps
and
and
things
like
that
on
this
list
and
I
already
talked
through
that
so
now,
I'm
gonna
go
and
I'm
gonna
hand
over
to
Santiago.
That's
gonna.
B
I'm,
my
backup,
you
guys
hear
me
okay,
so
as
Justin
was
mentioning
notaries
and
implementation
of
tough,
that's
optimized,
to
work
better
on
cloud
native
workflows.
So
it
is.
It
was
originally
developed
by
docker
all
of
the
companies
that
you
saw
on
the
right
hand,
side
of
the
graph
that
Justin
was
showing
and
it
was
L
in
conjunction
with
a
container
registry,
because
well
it
was
geared
towards
cloud
native
applications
to
give
a
little
bit
of
an
overview
I
the
way
that
notary
works.
B
C
B
B
B
So
I'm
going
to
jump
into
a
quick
demo
just
because
I
want
people
here
to
a
be
familiar
with
a
tool.
A
little
bit.
I
also
want
to
show
how
you
can
easily
start
playing
with
it.
I
know
that
the
developing
for
notary,
if
that's
something
that
you
would
like
to
do
and
I
highly
recommend,
it
may
not
be
very
obvious
from
the
get-go
it's
hard
to
get
started
so
I
have
this
here,
we're
back
there.
D
B
B
B
B
B
So
I
wrote
the
password
for
the
root
key.
This
created
the
root
key,
which
is
the
one
that
Justin
was
talking
about
for
recovery.
You
usually
want
to
take
that
root.
Key
put
it
in
a
safe,
safe
place,
probably
in
an
actual
safe,
may,
be
distributed
in
different
geographic
locations
in
case
there's
like
any
disasters,
and
then
I
will
have
a
targets
key.
B
Which
the
targets
key
is
the
one
that
I'm
going
to
use
to
sign
for
files
or
for
container
images,
or
anything
like
that,
and
finally,
I'll
have
a
snapshot
key,
which
is
the
one
that
let
me
know
that,
what's
the
state
of
the
repository,
this
is
part
of
the
the
role
separation.
That
Justin
was
talking
about.
B
So
I
did
it:
I
created
a
created
registry
I
have
all
the
keys.
If
this
wasn't
a
demo,
I
would
like
take
those
keys
and
put
in
different
places
and
in
a
way
that
it
makes
sense
for
my
operations,
team
or
my
or
my
individual,
like
needs,
and
and
now
that
I
did
this
I
will
add
a
file.
I
will
just
add
a
file
from
the
repository.
This
could
be
a
container
manifest
if
you're,
using
docker
content.
Trust
there's
like
a
seamless
way
to
pretty
much
quickly
pass
a
container
manifest.
B
B
B
And
I
also
think
I
made
a
type
of
somewhere,
okay
I'm
going
to
go
back
I'm
going
to
bail.
It's
a
sometimes
you
need
to
know
when
you
have
to
give
up
so
back
to
this
github.
We
have
a
github
robot
organization
that
hosts
both
of
the
implementations
and
there's
also
channels
on
the
cloud
native
slack.
If
you
want
to
participate
and
contribute-
and
you
can
also
reach
up
to
Justin
Cormac
or
Justin
Kappos
for
questions.
D
E
B
Pretty
much
points
to
a
registry,
so
it
is
signing
something
that's
living
on
a
registry:
okay,
whether
it's
a
container
manifest
or
a
blob.
It
really
doesn't
care
okay,
but
if
you
want
to
I
mean
you
could,
for
example,
use
target
content,
trust
and
just
enable
trust
to
sign
for
container
manifests
when
you
push
and
they
will
be
pushed
into
a
notary
server.
You
could
also
do
the
CLI
if
you
want
to
do
like
more
granular
control
over
what
you're
pushing
to
the
registry.
B
E
B
Example
say
that
you
want
to
pretty
much
just
signed
your
images,
push
them
to
docker
hub
and
verify
before
they
are
admitted
into.
So
there
is
a
part
of
the
docker
command
line
tool.
That's
called
docker
trust
and
you
can
do
dr.
trust,
I
think
it's
generate
and
you
generate
his
keys.
That
I
showed
you.
Then
then
you
can
do
darker
push
and
I
think
it
passed
sign
or
you
can
enable
there's.
B
A
environment
variable
called
a
docker
content,
trust
you
can
just
set
that
to
one
and
it
will
automatically
push
the
signature
information
into
either
the
docker
hosted,
where's
the
notary
or
into
the
one
that
you
want
to
push
through,
which
you
will
have
to
pedal
a
little
bit
with
the
configuration
mm-hmm
if
you're.
If
you
want
to
host
your
own
like
trusted
collections,
then
you
can
put
your
own
notary
server
in
your
organization
and
then
point
your
daughter,
clients
there.
B
Now,
on
the
admissions
side,
when
you
want
to
verify
I
recommend
using
a
an
admission
controller
called
Porteous,
which
you
basically
just
fiddle
a
little
bit
with
the
configuration
and
tell
it
well,
whenever
you
push
look
at
this
trust
registry
and
verify
that
any
image
that's
being
passed
through,
has
a
signature
by
a
trusted
party.
Okay,.
B
Pretty
much
you
can
think
of
it
like
that,
it's
a
signature
registry
that
allows
you
to
have
all
of
this
like
pretty
cool
security
properties.
Okay,
because
you
can
have
things
like
well,
if
the
people
are
building
base
images,
for
example,
the
official
images
are
being
signed
by
docker
and
you
can
have
things
like
well,
but
if
I
have
my
own
like
application,
then
it
needs
to
be
signed
by
somebody
who
I
trust,
so
you
have
that
namespace
and
that
key
well
in
a
sensible
way
architecture.
D
C
What,
if
I'm,
actually
less
worried
about
I,
mean
I'm
gonna,
I'm
gonna
key
my
images
forms
that
should
go
to
the
field
and
not
the
ones
that
are
built
by
the
developer
team.
So
I
don't
really
need
my
repository
to
not
admit
things
that
aren't
signed
because
many
may
have
it
just
won't
P.
What
I
want
to
make
sure
is
that
docker
doesn't
run
unsigned
images
in
the
field
but,
of
course,
runs
unsigned
images
in
my
building.
How
does
this
whole
work
together
to
achieve
that
result?
So.
B
C
B
C
B
Well,
the
benefit
is,
first
of
all,
that
there's
a
sign
policy
and
it
says
that
you
can
say
well.
I
am
doing
many
images,
but
the
ones
that
are
like
correctly
made
or
the
ones
that
are
like
for
you.
They
have
a
higher
like
trust
assurance,
and
you
can
it.
You
should
enable
this
just
so
nothing
wrong
happens.