►
From YouTube: Notary v2: Supply Chain Security for Containers - Justin Cormack, Docker & Steve Lasker, Microsoft
Description
Don’t miss out! Join us at our upcoming event: KubeCon + CloudNativeCon North America 2021 in Los Angeles, CA from October 12-15. Learn more at https://kubecon.io The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.
Notary v2: Supply Chain Security for Containers - Justin Cormack, Docker & Steve Lasker, Microsoft
Notary v2 is a community project to solve the issues that the existing Notary project has that have hindered widespread adoption. The project is a community initiative with the main registry operators, including Docker, Microsoft and Amazon, as well as a broad community of other interested parties and end users. We will provide an overview of the state of the Notary v2 project to build registry native supply chain security for containers, and will show how it fits in with other supply chain initiatives that are being worked on. We will outline the road to production for Notary v2, and remaining work to do.
B
Hi,
I'm
steve
lasker,
I'm
a
pm
architect
in
azure
work
on
container
registries,
including
acr
and
mcr,
and
as
part
of
that
you
know
with
registries,
we're
sitting
at
the
middle
of
all
of
the
services
in
azure
that
use
containers
from
production
services
the
devtools.
So
we
see
quite
a
lot
of
different
scenarios.
We
talked
to
a
lot
of
customers
around
the
various
scenarios
and
of
course
one
of
them
has
been
around.
How
do
I
sign
my
content
so
that,
as
I
consume
upstream
content
from
the
community
and
bring
it
into
my
environment?
B
How
do
I
know
what's
that?
And
how
do
I
promote
it
within
my
environment,
even
though
it
still
has
the
same
integrity,
so
notary's
been
a
key
focus
for
us
and
it
kind
of
builds
on
the
stuff
we
did
with
oci
artifacts,
I'm
a
tob
member
for
oci
and
a
maintainer
for
oci
artifacts,
which
is
how
we
leverage
registries
to
store
all
kinds
of
content
and
we'd
like
to
be
able
to
sign
all
kinds
of
content
so
that
there's
integrity
around
it.
B
A
That
so
what
why
are
we
doing
this
so
until
last
year?
Really
when
you,
I
used
to
have
a
much
longer
piece
in
here
about
why,
I
suppose
your
insecurity,
but
sailor
wins
last
year
really
kind
of
help.
People
understand
what
was
what
was
going
on,
that
someone
could
attack
some
software
attack
your
supplier
and
insert
some.
You
know
insert
malicious
code
into
their
software.
You
would
bring
it
on
prem
and
it
would
start
attacking
you.
B
A
A
And
often
if
people
want
to
attack,
then
sometimes
the
supply
chain
build
servers
and
things
are
the
weakest
link.
And
you
know
people
have
hardened
their
production
environments,
but
they
haven't
had
and
build
so,
let's
attack
build,
I
say
so
it
really
is
a
you
know,
something
that's
been
growing
in
importance.
A
Just
we're
just
recording
this
a
bit
ahead
of
time,
but
I
think
the
cncf
security
software
supply
chain
best
practices.
White
paper
should
be
out
for
kubecon.
It's
a
really
great
bit
of
work
if
you
want
to
have
more
background
on
supply
chain,
so
take
a
look
at
that
and
container
security.
I
think
it's
it's
kind
of
interesting
because
for
a
long
time
with
containers,
people
just
talk
about
things
like
you
know,
can
I
escape
from
a
container
like
treating
it
like,
like
those
boxes
like?
Can
I
get
out
of
the
box?
A
That's
not
really
what's
important
about
containers
and
shipping.
The
box
is
really
just
about
standardization.
The
important
thing
is
the
whole
process
by
which
you
know.
What's
on
your
container,
you
get
the
bill
of
lading
you.
You
know
you
can
trust
that
when,
when
it
arrives,
you
can
put
it
straight
into
your
supply
chain.
Your
factory
you've
got
the
metadata
within
about
what
what
it
is,
and
you
can
you
know
as
long
as
you're
as
long
as
doesn't
get
stuck
in
the
sewage
canal.
B
The
interesting
thing
about
this
also
is,
you
know:
you've
got
the
containers
on
the
left
and
then
you
have
this.
You
know
bill
lading
or
bill
of
materials.
If
you
will
that
says,
what's
in
it
and
like
okay,
justin
could
have
made
this
himself
on
some.
You
know
document,
but
there
is
a
stamp
on
it
and
the
stamp
has.
You
know
an
authenticity
to
it.
That
says
this
bill
leading
was
approved.
B
The
bill
leading
represents,
what's
in
the
container
and
there's
a
level
of
trust
associated
with
that,
and
that's
what
we're
trying
to
bring
with
containers.
There's
a
there's,
a
lock
on
the
container
that
says
it
wasn't
tampered
with.
There's
a
document
that
says
what's
in
the
container
the
bill
of
materials
and
there's
a
lock
on
the
document,
the
stamp
that
says
this.
This
is
accurate.
That's
a
really
good,
accurate
representation
of
what
we're
trying
to
accomplish
here
with
container
workflow
as
things
move
forward.
A
So
what
are
we
working
on
so
note?
3V1
was
created
back
in
the
2015
and
seems
a
long
time
ago
in
container
land,
when
containers
were
pretty
new
based
on
the
update
framework,
which
is
a
cncf
project,
and
it's
been
a
cnc
project
since
2017.
So
it's
you
know
one
of
the
one
of
the
earlier
projects,
it's
supported
by
some
registries
such
as
docker
and
azure,
and
ibm
and
harbor,
but
not
everywhere.
So
users
can't
rely
on
it
always
being
in
the
registry
which
is
kind
of
frustrating.
A
We
learned
a
huge
amount
from
the
rollout
how
people
used
it,
what
they
tried
to
do
and
all
those
things
which
is
really
feeding
into
the
design
for
v2
and
some
areas
we
really
want
to
fix.
You
know
these
are
some
of
them,
but
they're,
probably
the
most
important
ones.
First
of
all,
the
signature's
not
being
native
to
redresses
and
compatible
with
all
registries
as
a
real
problem.
A
Nowadays,
people
use
a
lot
of
registries.
You
know
you
might
you
might
use
you
might
get
some
images
from
docker
hub.
You
might
have
a
private
registry
on
azure,
you
might
have
jfrog
on
prem,
you
know
all
sorts
of
combinations
of
registries
and
for
different
purposes
and
different
stages
of
the
life
cycle.
So
that's
really
important.
Now
wasn't
so
important
back
in
2015
to
be
I
mean
where,
where
you
know.
B
B
Cycle
right,
we
want
to
be
able
to
consume
public
content,
whether
it
be
containers
or
package
managers
or
other
things,
but
we
want
to
bring
them
into
urine.
You
know
into
our
environment
into
the
environment
that
that
customer
represents
and
says
this
is
the
environment
that
I
trust,
there's
a
security
boundary
on
it
and
nothing's
randomly
getting
changed
on
me
even
for
good
or
bad
intentions.
B
A
Yeah,
absolutely
other
issues
were
a
lot
of
keys
to
manage
a
separate
key.
Well,
a
separate
set
of
keys
for
each
repository
which,
when
you
were
managing
repositories
at
scale,
was
really
difficult
to
manage
and
debugging
issues
was
complicated.
The
introspection
tooling.
Wasn't
it
wasn't
that
great
security
engineers
assumed
that
when
something
fails,
verifying
a
signature
that
that's
probably
a
hostile
attack
that
they've
just
thwarted
yay,
but
actually.
B
It's
more
than
debugging
to
it
right.
Also,
it's
just
that
balance
of
how
complex
does
something
have
to
be
to
solve
a
problem
because
the
more
complex
it
is,
the
more
places
for
things
to
fail,
the
more
difficult
it
is
to
use,
and
if
it's
difficult
to
use
and
complex,
it's
got
more
failures.
It's
not
going
to
get
as
much
adoption.
A
It's
important
that
people
understand
what's
going
on
and
they
can.
You
know
I
mean
I
think,
that's
what
debug
abilities
mean.
It
means
that
the
mental
model
of
what's
going
on
fits
with
your
with
the
real
reality
of
what's
really
going
on
behind
the
scenes.
I
think
there
was
a
few
issues
around
that
as
well,
and
then
there
was
kind
of
issues
around
registries.
A
The
tough
model
was
designed
to
run
package
repairs
where
you
only
have
the
current
content
in
and
whereas
registers
have
everything
in
and
that
didn't
fit.
So
well
with
the
update
model
and
in
the
update
framework,
and
there
was
just
kind
of
a
bit
of
a
mismatch
where
the
security
models
weren't
quite
right
and
we
needed
to
kind
of
tidy
that
up
a
bit.
A
We've
also
got
a
whole
bunch
of
new
requirements,
so
people
want
to
one
actually
one
of
the
first
things
people
started
asking
about
is
really
being
able
to
add
more
signatures
later
on,
so
people
often
have
this
workflow
they
want
to
where
they
want
to
mark
the
state
of
approval
of
something
by
signing
it
and
so
like
when,
when
this
is
approved.
For
production,
we
want
to
put
a
signature,
and
then
we
just
want
to
check
that
signature
for
prod,
but
that
wasn't
terribly
easy
to
do.
A
It
wasn't
the
kind
of
security
model
it
was
designed
for
with
v1,
and
then
there's
this
really
important
thing
about
adding
additional
mess
data.
So
you
want
to
add
that
bill
of
materials
you
want
to
add
other.
You
know
other
other
things
scan
reports
on
the
image
and
things
like
that
that
you
want
to
add
after
build,
and
you
want
to
sign
the
addition
of
that
so
that
people
can
validate.
That
is
you
know
you.
A
A
It's
a
community
project
with
very
broad
involvement
from
registries
and
end
users
and
cloud
providers,
all
sorts
of
people,
which
is
great,
so
we're
getting
lots
of
different
requirements,
but
we're
picking
the
things
that
we
can.
You
know
ship
it
earlier
that
have
that
help
people
right
now
and
laying
a
foundation
from
people
to
be
able
to
experiment
and
build
more
stuff
later
on
we're
going
to
get
the
base
infrastructure
out
there.
A
You
know
standard
centralization
and
oci,
and
you
know
as
well
in
terms
of
like
how
do
we
put
the
stuff
in
the
registry
formats
extensibility,
and
then
we
also
have
you
know
tooling,
which
we're
going
to
demo
to
you
shortly
about
prototype,
tooling
and
tools
for
policy
management,
and
you
know
wide
availability
and
interop,
but
we
want
to
let
you
know
we'll
start
with
flexible
base
tools
and
build
up.
You
know
if
people
want
to
do
people
have
specialized
requirements
and
want
to
build
specialized
tools.
That's
great
as
well.
B
It's
the
the
libraries
it's
right:
it's
not
just
the
tools,
like
the
tools
will
be
backed
by
libraries
and
specs,
so
that
you
can
use
these
libraries
in
other
scenarios
that
we
hadn't
thought
of.
I
mean
like
we're.
Not
trying
to
containers
are
used
in
so
many
different
places.
We
don't
you
know
we'll
talk
about
open
policy
agent
as
a
kubernetes
solution,
but
we
want
to
make
sure
that
you
can
do
wherever
you're
running
containers
like
with
container
d,
libraries
and
so
forth.
A
Absolutely
yes,
so
the
first
stage
work
in
progress
design
is
being
finalized
by
the
time
you
hear
this
talk,
it
might
be
finalized.
Hopefully,
so
we
will
be
able
to
give
you
more
notes
in
the
live
chat
during
the
while
you're
watching
this
kind
of
scope
it
as
kind
of
equivalent
to
git
commit
signing
for
containers.
A
So
it's
like
individual,
one-off
signatures,
not
a
kind
of
tough
update,
sign
a
sequence
of
containers,
type
thing
for
now
just
give
point
in
time
signatures,
there's
gonna
be
x,
509
support
because
lots
of
people
have
some
people
have
expert
509
infrastructure
and
people
want
to
use
that.
Not
everyone
has
infrastructure
now,
so
we'll
have
some
easy
tooling.
A
Anyway,
there's
lots
of
requirements.
We've
got
around
having
key
management,
for
example,
if
you
want
to
use
a
cloud,
your
cloud
service
to
manage
your
keys
or
vault,
or
something
like
that
or
you
have
want
to
use
hardware
keys
like
the
ubc.
I've
got
right
here,
those
kinds
of
things
you
know,
so
we've
got
a
lot
of
people
who
want
to
use.
A
B
A
A
A
pipeline
went
through
the
pipeline
stages,
and
this
software
is
one,
as
you
know,
one
piece
of
a
flow
of
updates
of
software
that
you're
going
to
feed
into
your
production
systems,
so
that
work
and
that's
intended
to
be
signed.
You
know
in
nci,
probably
with
ephemeral,
keys
using
spiffy
and
things
like
that.
So
that's
a
working
group
that
we're
gonna
we're
we'll
have
going
also
for
future
future
work.
A
B
Basically,
yeah,
we
have
container
images
that
we're
storing
in
registries,
and
the
interesting
thing
is
about
how
that
is
stored,
because
that
turns
out
to
be
very
generally
useful
for
a
number
of
different
things
that
we've
been
able
to
put
in
registries-
and
you
know
up
till
today
or
up
until
artifacts,
were
created,
the
oc
artifacts
project.
People
were
stuffing
all
kinds
of
things
in,
but
making
them
look
like
container
images
like
the
old
way
we
used
to
change
the
the
extension
on
the
file
when
we
try
to
attach
it
to
an
email.
B
B
The
new
thing
that
we're
adding
is
the
ability
to
add
a
reference
from
that
signature
to
the
image
and
the
directionality.
There
is
pretty
important
if
you
notice
the
the
image
points
down
to
the
layers
and
the
signature
points
to
its
blob.
That
contains
a
signature,
but
it
also
has
this
reverse
lookup
reference
that
says:
hey.
A
B
But
if
you
want
to
add
yet
another
artifact
type
yeah,
you
can
do
that
as
well
stored
as
an
artifact
at
a
registry,
give
it
the
reference
to
what
it
associates
with
and
now
you
have
starting
to
build
this
graph
and
just
like
we
saw
with
the
bill
of
lading
of
the
ship
the
bill
of
build
materials.
Here
we
have
a
signature
on
it
to
make
sure
it's
attested
to
so.
B
If
you
look,
there's
this
interesting
graph
of
artifacts,
of
which
one
of
those
things
artifacts
types
is
a
signature
and
that's
the
fundamental
concept
that
we've
been
working
on.
So
with
that,
let
me
see
I'll
do
a
little
screen
share
switch,
and
so
what
we've
done
is
for
the
purpose
of
this
experience.
We've
added
a
plug-in
for
docker
and
if
you
notice,
there's
build
x,
for
instance,
as
a
plug-in.
B
There's
nv2
that
we've
also
put
as
a
plug-in
as
well
so
just
to
make
things
a
little
easier
to
not
have
to
type
docker
mb2
every
time
I'm
just
going
to
create
an
alias
and
I'm
also
going
to
just
create
a
environment
variable
for
my
artifact
name.
The
net
monitor
v1
image
I'll
just
create
as
an
alias
now.
The
first
thing
we'll
do
is
just
kind
of
do
a
docker
build,
so
I'm
going
to
build
and
I'll
tag
it
that
fully
qualified
name
and
you
know
voila.
I
now
have
an
image.
B
Image
here
now,
we
want
to
be
able
to
support
ephemeral
clients
that
are
boot
up
in
each
time.
They're
being
runs
they're,
always
in
a
refreshed
state,
but
we
also
want
to
be
able
to
support
signing
before
it
ever
leaves
that
environment.
So
what
I'm
going
to
do
is
enable
notary
and
again
these
are
just
temporary
names.
Naming
is
hard
we
just
this
is
just
what
we've
done
for
now
and
I'm
going
to
say,
docker.
B
B
So
now
I
can
say
docker
push
and
because
we
have
this
plug-in
that
we've
extended
for
docker,
which
is
you
know,
it
represents
the
experience,
we're
shooting
for
it,
it'll
change,
but
an
example
that
what
we've
done
is
we've
pushed
this
the
image
and
the
signature
and
there's
a
link
between
the
signature
and
the
image.
So
now.
B
Already
pushed
that
graph
into
the
registry,
so
we
talked
about
a
set
of
libraries
that
we're
adding.
Let's
see
if
I
can
paste
that
clearly,
one
of
the
libraries
we've
been
using
around
artifacts
is
something
called
ores,
oci
registry
as
storage,
and
something
a
couple
of
some
folks
put
together
to
enable
this
experience
and
we've
added
a
discover
api.
B
B
B
A
B
B
So
I
don't
have
anything.
I
got
nothing
on
my
sleeves
right.
We
only
have
the
registry
running
is
the
point
here
so
now
I
want
to
simulate
another
client,
so
I'll,
say
docker,
paul,
pull
that
image
and
what's
happening
here.
Is
it's
saying
that
oh
wait?
I've
got
my
signature
already
set
up.
Sorry
hold
on
a
second
see.
This
is
the
demo
failure.
B
Let
me
fix
one
thing
jumped
ahead,
so
let
me
reset
that
because
so,
if
I
say
docker
image
pull,
if
I
do
not
have
my
client
configured,
which
is
what
I
want
is
it
found
a
signature,
but
there
is
no
keys
on
my
machine,
so
it
basically
says
I
found
this
image,
but
you
have
no
keys
that
match
it.
So
I'm
not
going
to
allow
that
image
to
be
pulled.
B
If
I
cap
the
output
of
our
configuration
for
the
nv2
client
configuration
there's,
no
certain
certificates
referenced.
That's
why
it
didn't
work.
If
I
go
and
change
that
and
put
a
certificate
in
the
path
for
it
to
find
now
when
I
say
docker
pull,
because
I've
got
that
signature,
it'll
say
I'm
going
to
pull
and
the
pole
has
got
an
extension
to
it.
So
the
poll
will
first
pull
the
manifest,
find
any
references
and
it'll
go
iterate
through
the
references,
look
for
signatures,
specific
signature
types
and
then
match
those
with
the
key.
B
All
of
that's
happened
before
the
image
was
ever
even
pulled,
so
there's
no
trojan
horse
style
attack.
It
was
able
to
verify
that
one
one
of
the
signatures
matches
one
of
the
keys
I
have
locally
and
then
it
proceeds
with
the
image
pull.
So
if
I
look
at
my
image
cache
locally
now,
I've
got
the
net
monitor
image
here,
because
I
have
the
server
but
wait.
There's
more
so
we
said
we
wanted
to
be
able
to
talk
about
s-bombs,
so
we're
going
to
go,
create
the
world's
most
simplest
assessment.
B
And
if
we
look
at
it
here,
we'll
see
you
know
it's
got
some
version,
which
is
none.
It
references
an
image
and
it
says
it's
good.
So
it
must
be
good
right,
it's
not
great!
It's
not
awful,
it's
just
good.
Clearly,
this
is
not
the
kind
of
s-bomb
we
want
to
ship
in
production.
The
idea
is,
there
could
be
anything.
B
Any
files
could
be
pictures
of
cats
and
dogs,
whatever
there's
some
document
that
gives
some
information
around
that
image,
and
I
want
to
be
able
to
push
that
to
a
registry
as
an
artifact
that
is
linked
to
the
image.
So
I'm
going
to
push
this
sbom
json
document
the
thing
we
just
created,
I'm
going
to
push
it
to
this
repo
notice,
there's
no
tag.
B
We
don't
see
linked
artifacts
as
needing
tags
because
they
really
have
no
value
unto
themselves
they're
in
addition
to
the
original
original
image
original
artifact.
So
if
the
net
monitor
image
is
deleted,
we
want
the
s-bomb
the
signatures
and
everything
to
delete
with
it
just
like
when
we
copy
it.
We
want
them
to
go
with
it.
So
we're
going
to
push
this
file
to
this
repo,
we'll
say
it's
an
artifact
type
of
example:
s
bomb
v,
zero,
so
clearly
nothing.
B
It's
referencing,
an
artifact
reference
to
the
net,
monitor
image.
We
reference
it
as
a
tag,
but
it
will
convert
it
to
a
digest.
We
don't
ref,
we
don't
link
to
tags,
we
link
to
digests
and
we're
going
to
save
that
manifest
because
we're
going
to
sign
that
in
the
next
step,
so
that
simple
we've
created
that
taken
that
s
bomb
and
pushed
it
to
the
registry,
and
we
can
see
that
by
simply
using
our
or
as
discovery
api
again,
so
we're
going
to
discover
the
anything
that's
referenced
to
the
net,
monitor
v1
image.
B
And
if
we
look,
we
see
here's
the
net
monitor
v1
image
and
we
notice
here's
our
artifact
type
of
an
s-bom,
v1,
v0,
sorry
and
there's
our
s-bom
content
is
stored
in
this
tar
file
and
then
the
manifest
it
points
to
it's
pointing
at
our
container
image.
So
that's
that
reverse
lookup
reference
back
to
the
container
image
and
notice.
We
also
have
an
artifact
type
of
notary,
v2
signature,
so
those
things
are
both
linked
to
the
artifact
to
the
image.
At
that
point
because
notice,
the
signature
also
points
back
to
that
same
image.
B
B
So
the
first
thing
I
need
to
do
here
is
save
that
digest
for
the
signature,
and
now,
when
I
say
nv2sign
or
mb2s
are
binary,
but
there's
libraries
that
back
it
up,
you
can
use
I'm
going
to
use
that
x509
insert
of
the
networks,
rabbit
wabit
networks
key
and
I'm
going
to
reference
the
thing
I'm
signing,
which
is
this
s
bomb
document.
I
want
to
sign
it
and
push
it
associated
with
the
s
bomb
in
this
case,
not
the
image
but
the
s
bomb.
B
A
So
how
they
get
involved,
this
is
our
places
to
places
to
find
us
is
the
central
thing:
is
the
cncf
slack
notary,
v2
meetings
on
the
cncf
calendar
projects
on
github
meeting
notes,
it's
all
very
everything's,
open
and
available.
The
recordings
are
on
youtube,
so
please
come
along
and
get
involved
come
talk
to
us
if
you're
interested-
and
you
will
be
in
the
chat
with
more
more
to
tell
you
about-
what's
going
on
right
now,
rather
than
a
few
weeks
ago,
because
everything's
moving
pretty
fast
right
now.