►
Description
Don’t miss out! Join us at our upcoming events: EnvoyCon Virtual on October 15 and KubeCon + CloudNativeCon North America 2020 Virtual from November 17-20. Learn more at https://kubecon.io. The conferences feature presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.
Notary v2 Introduction and Status Report - Justin Cormack, Docker & Omar Paul, Amazon
The Notary v2 project is a rework of the infrastructure for container signing, supporting additional OCI Artifacts, such as Helm, Singularity and CNAB. It addresses the design and usability issues that have been found with Notary v1, and signing in a multi-registry world. The major focus being signatures as first class elements of registries rather than running a sidecar database. It addresses the signing usability issues enabling broad provider and customer adoption. This session will give an overview of the Notary v2 community project at present, and the roadmap. This session is for anyone interested in container signing and what the new project is working on.
https://sched.co/Zewy
A
Hello
today
we're
covering
the
notary,
v2
introduction
status
report,
so
we've
been
working
on
a
second
version
of
notary
for
a
while
and
there's
an
advanced
talk
later
on
going
through
some
of
the
detailed
work,
but
this
is
really
introducing
where
we
are
and
what's
going
on.
This
is
a
joint
thing
with
me
and
homer
paul
from
amazon,
I'm
a
notary
maintainer.
A
A
A
It's
often
embedded
in
more
opinionated,
tooling,
so
docker
content
trust
was
something
we
built
a
docker
that
made
kind
of
easy
to
use,
workflows
for
signing
and
cnab
is
doing
something
similar
using
nature
as
well.
So
so
it's
you
know,
it's
the
server
implementation
and
it's
it's
a
set
of
libraries
and
tooling.
You
can
use
directly,
but
ideally
it's
got
a
nicer
wrapped
interface
in
something
else
in
the
enterprise.
A
Consulting
assigning
is
really
about.
Having
easy
integration
supply
chain
we're
going
to
talk
about
supply
chain
in
a
minute,
validating,
storing
and
displaying
the
images
you
want,
setting
up
policies
around
signatures
to
make
sure
that
things
that
are
run
in
production
are
signed,
making
sure
that
we
have
freshness
and
immutability
and
so
on,
which
are
some
of
the
guarantees
that
tough
helps.
Give
you
in
it's
not
free
about
to
make
sure
that
you
are
actually
getting
the
latest
version
of
an
image,
and
this
is
part
of
your
governance.
A
You
know,
you've
got
central
governance
and
compliance.
You've
got
to
answer
to
auditors
about
your
governance
and
you've
got
to
manage
and
audit
the
history
of
the
artifacts
that
went
into
production
and
know
that
they
were
exactly
what
you
thought
they
were
because
the
last
thing
we
want
to
do
is
have
things
go
into
production
they're,
not
what
we
thought
they
were.
A
Automated
deployments
are
kind
of.
I
mean
obviously
they're
a
foundation
of
what
we
do
in
cloud
native
and
continuous
deployment
is
one
of
the
key
pieces
of
cloud
native
workflows,
but
they
do
provide
new
attack
factors
if
you
one
thing
that
attackers
have
noticed
recently
is
that
if
you
protect
your
production
infrastructure,
then
maybe
it
becomes
easier
to
attack
the
deployment
infrastructure
and
there's
been
a
lot
of
interesting
cases
which
we'll
look
at
in
a
second.
A
This
is
a
great
article
from
gartner
from
2018
around
on
container
security,
I'm
covering
threat
factors
in
an
automated
deployment
process,
and
you
can
see
everywhere
those
little
red
arrows.
There
are
places
you
can
attack
so
everywhere
from
the
developer's
laptop
right
at
the
beginning
through
to
dependencies
and
deployment
systems
and
registries-
and
you
know
everything
really
up
to
you-
know
up
to
production.
A
Some
recent
examples
of
supply
chain
attacks
that
we've
seen
there's
a
these,
are
kind
of
high
profile
ones,
but
they've
and
they're
definitely
becoming
more
common
asus
shadowhammer
updater
attack
was
added
code
before
the
script.
You
know
the
automated
piece
of
deployment
that
did
the
signing,
so
everything
was
signed
and
it
was
an
interesting
one
because
it
was
only
act.
The
hack
was
only
activated
on
55,
specific
mac
addresses,
so
most
users
didn't
notice.
A
Anything
was
wrong,
but
55
computers
in
the
world
were
being
targeted
for
being
attacked,
which
is
kind
of
interesting,
there's
also
similar
with
the
mpm
event
stream
of
hack
and
in
2018,
where
this
is
where
an
attacker
helpfully
offered
to
maintain
an
unmaintained
open
source
project
seemed
a
nice
thing
to
do
and
inserted
a
back
door
targeted
it
specifically
at
developers
of
a
particular
application
again.
So
again,
most
users
didn't
notice.
A
They
didn't
alert
anyone
because
nothing
weird
happened,
but
these
developers
were
being
targeted
and
then
not
purcha
in
2017
again
ship
fire,
an
update
to
a
tax
management
program
that
is
widely
used
in
much
of
europe
and
then
from
there.
It
went
and
attacked
other
users
again.
The
update
was
signed
by
an
automated
process
and
the
bill,
because
the
build
server
was
totally
compromised,
damages
from
that
were
estimated
10
billion
dollars.
A
A
A
So
we
want
it
to
be
secure
and
to
have
clear,
understandable
security
properties
that
people
really
get
and
there's
a
whole
bunch
of
things
we'll
talk
about
there,
so
registry
native.
We
really
want
all
the
data
basically
stored
in
the
registry,
not
in
a
separate
database.
This
is,
it's
turned
out
to
be
a
really
important
thing
and
it's
kind
of
come
up
a
lot,
because
people
are
using
registries
to
store
more
things,
not
just
container
images
such
as
helm,
charts
and
so
on,
and
there's
an
ecosystem
around
the
registry.
A
Azure
and
harbour
supports
it,
but,
for
example,
amazon
does
not
at
the
moment
and
many
other
registries.
Don't
so
you
don't
know
if
you're
going
to
be
able
to
use
signatures
which
is
kind
of
un
helpful.
If
you
want
to
move
things
around,
the
apis
are
not
designed
for
moving
signatures
around
easily
either.
There's
no
simple
push
and
pull
api.
A
So
we
really
want
it
to
be
that
you
know
when
you
push
and
pull
images
between
registries,
the
signatures
come
with
them
as
well,
and
we
want
to
validate
signatures
wherever
the
content
is
located.
There
was
some
issues
around
notre
dame
v1
making
some
assumptions
about
the
registry
where
the
signature
was
is
the
same
as
the
registry.
You
pull
from
that
caused
a
bunch
of
issues.
A
People
also
want
to
use
signing
not
in
a
registry,
we've
had
a
lot
of
use
cases
being
brought
up
where
people
want
to
use
containers
in
offline
and
disconnected
environments.
This
wasn't
really
much
of
a
use
case
when
we
designed
notary
v1.
It
does
have
some
tooling
to
support
that,
but
it's
not
ideal.
A
It
wasn't
really
a
design
requirement
at
the
time
it
you
can
kind
of
make
it
work,
but
you
have
to
know
what
you're
doing
if,
if
we
have
a
standard
mapping
between
the
registry
and
and
faster
to
mapping,
say
for
local
use,
then
as
much
or
a
cached
offline
registry
that
you
can
use
or
whatever,
then
that's
much
easier.
So
we
really
want
to
support
those
use
cases.
A
lot
of
people
say
that
they
are
not
always
connected
to
the
internet
at
all
times.
A
A
After
a
few
kind
of
years
at
docker,
we
decided
that
they
were
not
really
suitable
for
end
users
and
we
introduced
a
set
of
docker
trust
commands
to
make
a
more
friendly
interface.
But,
although
that's
a
covers
only
quite
an
opinionated
workflow
on
how
to
use
notary,
it
doesn't
give
you
all
the
options
that
upstream
gives
you,
but
it's
way
easier
to
use.
A
It's
still,
there's
still
difficulties
even
with
that
kind
of
simpler
interface,
but
I
think
it
gives
us
an
idea
of
what
kind
of
you
know
is
what
kind
of
interfaces
are
better,
but
the
the
other
problem
was
key
management.
There's
a
lot
of
keys
with
an
a3
v1,
there's
a
root
key
for
every
registry
repository,
so
a
normal
user
might
have
a
lot
of
different
route
keys
and
an
organization
might
have
hundreds
of
thousands
even
of
root
keys,
and
then
there
are
the
other
keys,
as
well
as
the
root
keys
that
derive.
A
So
you
end
up
with
a
very
large
number
of
keys
to
manage
keys.
Then
expire
users,
not
very
good,
at
remembering
to
do
things
about
keys
when
they
expire,
we
most
people,
I
think,
went
for
long-lived
keys.
So
the
expiry
time
was,
you
know,
it's
expiry
was
not
something
that
was
people
managed
very
often.
A
So,
as
we
learnt
with
tls
the
less
often
you
expire
keys,
the
more
annoying
they
are
and
users
are
really
not
used
to
managing
that
kind
of
scale
of
keys,
and
so
we
have
we've
had
a
lot
of
problems
with
with
that
from
a
usability
point
of
view,
you
know
backups
and
all
those
kinds
of
things,
so
we
really
need
to
improve
the
key
management
side
of
usability
and
as
well
for
your
v2,
understandability
and
debuggability.
I
think
we.
A
It's
definitely
the
case
that
most
people
don't
understand
the
security
model.
That
tough
is
using
and
that's
partly
our
fault,
but
for
not
explaining
it
clearly.
But
it's
also
it's
partly.
The
interfaces
are
not
that
great
for
actually
understanding
you
know
and
observing.
What's
going
on
and
understanding
when
failures
happen,
and
this
is
a
sort
of
it's
partly
a
documentation
issue
and
partly
an
observability
issue
and
partly
a
a
design
issue
and
partly
an
education
issue.
A
This
image
actually
means
and
that's
kind
of
people
have
a
an
intuition
which
isn't
always
what
the
system
is
providing
and
that's
really
difficult
to
deal
with,
sometimes
because
intuitions
are
kind
of
difficult
to
change,
so
we've
got
a
lot
of
work
to
do
there
and-
and
it's
you
know
very
obvious,
even
in
the
process-
that
working
with
people
who
are
familiar
with
these
things-
that
it's
not.
Actually,
it's
not
actually
the
easiest
thing
in
terms
of
usage
and
adoption
notre
v1
usage
is
not
that
high.
A
It's
you
know,
kind
of
when
when
we
were
designing
the
previous,
the
present
system
that
came
before
notary
v1
every
image
was
signed.
That
wasn't
a
great.
So
arguably
you
could
say:
oh
everyone
used
it.
It
was
great,
but
in
practice
it
had
other
issues
about
every
image
was
signed,
but
there
was
no
reasonable
way
of
knowing
which
keys.
You
should
trust.
So
it
didn't
the
signing
didn't
really
actually
matter,
but
the
yeah,
the
usage
is
just
not
as
high
as
we
would
like.
A
A
We
want,
as
I
said,
the
security
properties
to
be
understood
and
understandable
and
well
written
well
explained,
but
we
also,
I
think,
there's
a
big
feeling
that
we
don't.
We
want
to
work
with
the
way
that
people
use
container
images
now,
rather
than
tell
people
that
they
have
to
use
things
differently
in
order
to
get
security,
because
that
way,
they'll
probably
decide
to
carry
on
using
things
the
same
way
because
of
familiarity
so
we'd
right.
We
don't
want
to
be
sitting
there
telling
people
their
workflows
are
wrong.
A
Although
I
mean
there
are
definitely
issues
with
how
the
workflows
are
and
the
things
we
should
probably
do
over
time
to
make
them
better.
But
the
goal
is
not
to
prescribe
a
workflow
and
then
say
this
workflow
is
secure
and
other
workflows
are
not
secure,
because
then
I
guess
in
the
way
of
adoption,
but
some
of
the
security
properties
are
different.
A
A
A
V1
that
you
know,
I
think,
is
a
is
not
giving
people
the
security
guarantees
that
they
would
think
they
were
getting
because
notary
v1
gives
you
tough,
but
it
gives
you
a
version
of
taft
that
has
a
different
key
management
decision
and
that's
problematic,
actually
nursery
technically
gives
you
a
choice
of
key
management,
but
the
implementation
that
almost
everyone
uses
is
the
trust
on
first
use.
One
so
yeah,
you
can
actually
implement
different
decisions,
but
I'm
not
aware
of
very
many
people
who
do.
A
A
So
the
plan
we've
been
working
on,
we've
been
working
on
requirements
and
trying
to
get
everyone
aligned
and
so
we're
getting
towards
agreement
on
these
things.
Obviously,
now
at
cubecom
we're
going
through
and
talking
to
everyone
about
where
we
are,
what
we're
doing
there's
more
in
the
in
the
working
session,
we
are
working
on
beginning
prototypes
as
well.
A
A
Some
of
the
discussions
are
ongoing
again
something
we're
talking
about
in
the
coming
session,
and
some
of
the
things
we've
already
had
kind
of
discussion
on.
One
of
them
has
been
about
adding
signatures
and
content
addressability,
so
registries
are
content,
addressable
stores,
and
what
that
means
is
that
everything
is
defined
by
the
hash
of
the
content
you're
referring
to
so
the
contents
of
an
image
define
it
uniquely
in
the
storage.
A
So
if
you
want
to
retrieve
the
signed
object,
you'd
have
to
specify
the
hash
of
it
with
the
signatures.
And
then,
if
you
added
another
signature,
it
would
change.
So
there's
def,
there's
a
working
group
around
adding
an
api
to
registries
that
can
given
an
object,
retrieve
all
the
signatures
attached
to
it.
As
a
separate
item
you
will
still
probably
be
able
to.
I
mean
you
should
be
able
to
still
refer
to
the
signatures
directly.
A
Another
thing
that
would
I
talk
about
in
the
in
the
other
session
in
more
detail
is
more
about
ephemeral
servers.
Ephemeral
surfaces,
as
I
said,
are
really
important,
but
they
do
it
have
security
implications,
and
this
is
something
that
really
hasn't
been
looked
at
much
before.
I
think,
but
one
of
the
guarantees
that
taft
gives
you
is
about
rollback.
A
So
it
says
that
if
you've
downloaded
something,
no
one
can
come
along
later
and
say,
delete
all
the
new
versions
and
then
tell
you
that
the
latest
version
of
the
package
you're
looking
for
is
the
one
from
two
years
ago.
That
happened
to
have
a
security
vulnerability
because
you
would
detect
this
had
been
rolled
back
because
you'd
seen
versions
earlier,
but
an
ephemeral
server
kind
of
doesn't
have
any
of
that
state.
A
Another
thing
we've
talked
about
a
lot
of
what
guarantees
users
are
expecting
with
signing
whether
they're
you
know
how
much
how
many
guarantees
do
they
want?
What
what's
the
expectation
about
what
signing
means
and
those
kinds
of
issues
around
you
know
which,
which
security
properties
are
you
getting?
Is
it
guaranteeing?
A
What's
it
guaranteeing
about
the
software
you're
downloading,
and
then
we
obviously
have
a
lot
of.
We
have
a
working
group
on
key
management,
there's.
Obviously
discussions
around
what
kind
of
keys
to
use
like
x509,
gpg
or
ad
hoc
signing,
where
the
trust
is
built
into
the
actual
signature
protocol
and
the
the
whole
workflow
that
we'd
be
designing,
and
so
we'll
talk
about
that
more
in
the
other
session.