►
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
Using TUF to Mitigate Repository Compromises - Marina Moore, NYU & Justin Cappos, NYU
The secure distribution of software is critical to the overall security of a system. In this talk, Justin Cappos and Marina Moore will provide an introduction to The Update Framework (TUF), a CNCF project that has been used throughout the cloud native community for compromise resilient software updates. TUF provides a flexible framework for secure updates even through a compromise of signing keys or the update repository. You will come away from this talk with an understanding of why secure distribution of software is important and how TUF can be used to achieve this goal.
https://sched.co/Uaio
A
Who
here
knows
about
tough,
know
something
about
tough
Wow?
Okay,
so
you
were
you're
the
only
person
who
didn't
at
least
do
a
hand
waggle.
Okay,
that's
great,
that's
great,
so
that
this
talk
will
be
mostly
directed
to
you
because
of
the
introductory
session.
Great
I'm
glad
to
hear
that,
and
so
I
would
imagine
that
most
of
you
are
using
tough.
In
fact
it
imagine
everyone
in
this
room,
who's
deploying
things
is
using
tough,
whether
you
know
it
or
not.
But
anyway,
let
me
not
steal.
A
A
A
These
are
actually
a
really
scary
sort
of
scenario
to
find
yourself
in
because
what
happens
is
is
that
if
someone
goes
and
breaks
in
and
for
instance,
breaks
into
you
know
repository
that's
serving,
you
know
like
a
bunch
of
open-source
software
like
Apache
and
other
things
like
that,
you
can
imagine
that
you
can
have
an
enormous
number
of
users
potentially
be
compromised.
I
spend
lots
of
instances
where
this
has
actually
happened.
A
So
when
the
best
hackers
in
the
world,
where
I
would
argue
the
best
hackers
in
the
world
or
a
lot
of
the
nation-state
actors,
the
people
that
you
know
go
and-
and
you
know-
are
doing
things
inside
major
governments
of
the
world
and
and
cultivating
and
building
those
skills
and
acquiring
cyber
weapons
and
attacking.
So
we
have
a
situation
where
some
hackers,
allegedly
the
United,
States
and
allegedly
Israel,
hacked
into
Iran
for
the
purposes
of
gathering
reconnaissance
and
damaging
centrifuges,
and
they
did
this
by
two
pieces
of
malware.
One
was
called
flame.
A
The
other
was
called
Stuxnet
stucks,
it's
the
one
that
got
a
lot
of
the
press,
because
it
was
the
thing
that
actually
caused
the
centrifuges
to
malfunction.
But
it's
a
very
simple
piece
of
malware,
complete
compared
to
flame
flame
was
a
piece
of
malware
that
was
actually
spread
via
a
couple
of
different
issues
and
design
flaws
in
Windows
Update,
including
some
of
those
that
we
talked
to
Microsoft
about
before
flame
hit.
A
Also,
South
Korea
was
hit
by
an
attack,
allegedly
by
North
Korea,
that
caused
over
three-quarters
of
a
billion
dollars
in
damage
to
their
economy,
and
we
saw
this
like
not
Pecha,
ME
doc
hack
that
you
guys
said
recently
where
it
was
allegedly
Russia
attacking
Ukraine,
but
then
that
spilled
over
and
hit
a
whole
bunch
of
hospitals
and
businesses
all
around
the
world.
So
this
is
a
big
problem.
A
Okay,
so
in
the
threat
model
and
the
thing
that
tuff
is
concerned
about
and
tough
worries
about,
is
we
want
to
be
worried
about
situations
where
attackers
can
do
a
variety
of
attacks?
So,
of
course
they
can
do
a
man-in-the-middle
monkey
in
the
middle,
whatever
you
want
to
call
it
sort
of
attack,
but
they
can
also
do
some
very
serious
things
like
we're.
Assuming
that
attackers
can
break
in
and
steal
signing
keys,
they
can
break
into
repositories.
They
can
break
into
servers.
A
They
can
bribe
a
you
know,
somebody
working
for
a
company
or
do
other
things
like
this,
so
this
is
really
meant
to
provide
you
the
best
possible
protection
you
can
have
in
these
cases-
and
you
know,
if
you
know
one
of
the
main
takeaways
here
is-
is
that
in
practice
you're
never
going
to
be
able
to
completely
prevent
there
from
being
a
compromise.
So
instead
what
you
want
to
do
is
you
want
to
limit
the
impact
so
make
it
hard
for
compromises
to
happen,
but
then
make
it?
A
So
even
when
they
do
happen,
it's
not
a
fatal
kind
of
world
ending
event
when
it
occurs.
Okay,
and
just
because
it's
helpful
sometimes
for
some
people,
especially
if
they
want
to
kind
of
make
this
case
to
their
you
know
to
their
boss
or
somebody
like
hey.
Why
do
we
need
this
like?
Why
can't
we
use
GPG
or
whatever
else
so?
First
off
we
look
when
you
go
to
produce
information
like
software
that
you
want
to
have
installed,
you
produce
something
that
you
know.
A
We
can
call
an
image
like
a
software
image
you
this
could
be
packaged.
This
could
be
whatever
it
is,
for
this
specific
type
of
system
that
you're
trying
to
install
and
there's
also
metadata
that
you
produce
that
talks
about
this
thing,
that
it
is
that
you
want
to
go
and
provide,
and
so
there's
a
few
different
ways
to
try
to
protect
this
information.
A
But
different
organizations
have
different
ways
of
going
and
providing
this,
and
so
there's
a
big
problem.
If
you
have
this
kind
of
online
key,
whether
it's
something
like
an
HSM
that
maybe
you
keep
in
your
build
server,
that
does
signing
of
things
automatically
or
whether
you
have
a
repository
we're
in
the
it.
A
Your
HSM
hasn't
really
helped
you
in
any
way,
okay,
so
yeah.
So
you
have
this
problem.
So
the
real
message,
like
the
the
one
sentence
message
from
this
talk,
is
that
if
you're
not
operationally
perfect
on
security,
then
you
need
something
like
time.
You
need
something
that
that
doesn't
put
all
your
eggs
in
one
basket
that
doesn't
assume
you're
gonna,
be
perfect
and
then
fail
horribly.
If
you
ever
make
a
mistake,
okay
and
tuff
was
designed
to
expressly
protect
against
situations
where
you
would
make
you
know
it's.
A
It's
meant
to
allow
you
to
have
errors
and
make
mistakes
and
still
recover
in
a
good
way
and
also
have
it
where,
when
you've
made
a
mistake,
it's
not
necessarily
fatal.
Even
when
some
bad
thing
like
let's
say,
if
docker
hub,
for
instance,
were
to
happen
to
get
compromised,
it
doesn't
it's
not
the
end
of
the
world
for
everyone
who's
you
know
going
and
and
using
that
to
store
their
container
images
all
right.
So
the
way
that
this
works
with
toth
is
by
using
five
different
principles.
A
I'm
gonna,
just
kind
of
quickly
go
through
these
I'm
happy
to
go
in
more
detail
about
any
of
this.
You
know
if
it's
if
there's
interest
in
this,
but
I
just
want
to
give
kind
of
an
overview.
So
you
get
some
of
the
high-level
ideas
about
why
tough
itself
might
work,
although
this
is
not
a
deep
dive
and
we're
not
going
to
be
going
in
and
looking
at
exact
metadata
files
and
I'm
not
going
to
be
talking
about
what
a
lot
of
these
boxes
here
mean
other
than
at
a
very
high
level.
A
Okay,
so
one
of
the
first
and
primary
design
principles
of
tough
is
to
have
separation
of
duties.
So
the
idea
is
is
that
you
might
have
different
parties
that
have
different
keys
and
have
different
responsibilities
and
different
abilities
to
do
things.
So,
for
example,
I
have
someone
who
manages
my
grants
at
the
University
and
they
have
access
to
a
bunch
of
like
financial
information,
not
just
from
my
grants,
but
for
other
grants
that
they
manage.
A
Ok,
yet
I
have
access
to
things
that
they
don't
have
access
to
like,
for
instance,
if
I
teach
a
class
I
have
access
to
grades
and
whatever
else
and
of
course
we
have
some
overlapping
access
at
times
in
that
role.
So
it
isn't
that
there's
necessarily
a
strict
hierarchy
of
things,
but
there's
the
ability
for
people
to
have
different
roles
and
to
fulfill
different
roles.
A
Another
example
of
this
is
that
you
know
an
administrative
assistant
who
helps
me
out
has
a
key
to
be
able
to
get
into
my
office,
as
does
a
janitor
who's
able
to
go
and
get
into
every
office,
but
the
janitor
doesn't
have
access
to
get
into
my
desk
drawer,
which
is
locked
or
other
things
like
that.
So
you
can
see
that
that
you
have
different
ways
of
doing
this.
A
Another
property
that
that
tuff
has
is
stuff
has
the
ability
to
have
threshold
signatures,
and
the
easiest
analogy
to
think
of
is
a
real
world
analogy
with
this.
So
when
they
have
nuclear
submarines
and
they
want
to
be
able
to
launch
the
missiles.
What
happens
is
that
there's
two
keys
that
are
very
far
apart
in
the
submarine
that
have
to
be
turned
at
the
same
time?
And
so
this
makes
it
so
that
one
person
who
goes
crazy
and
steals
keys
and
does
whatever
else
can't
cause
the
nuclear
warheads
to
be
launched
right.
A
So
in
tough,
you
can
have
a
similar
thing
where
you
can
say,
for
instance,
I
can
go
and
say:
well,
you
know
of
the
tough
maintainer
'he's
two
of
the
five
of
us
have
to
sign
off
on
a
release
of
tough.
In
order
for
that
release
to
be
considered
a
valid
release,
so
I
could
sign
with
marina
we
could
have
Santiago
and
Lucas,
or
you
know,
other
developers
of
ours
go
and
sign
it
and
do
this,
but
you
have
to
have
a
threshold.
One
of
us
can't
just
go
crazy
and
say
AHA.
A
This
crypto
minor
is
now
the
new
version
of
tough
okay.
One
thing
that
I
think
we
did
very
well
inside
of
Toth
is
from
the
outset.
Our
goal
was
to
deal
with
and
protect
against
compromises
into
worried
about
people
breaking
into
the
system.
That
was
the
goal
when
building
tough
and
if
you
compare
this
to
systems
like
GPG
or
you
look
at
the
whole,
like
x.509
architecture,
I,
don't
think
anyone
here
would
look
at
those
and
say
they
were
clearly
designed
with
revocation
and
Trust
removal
as
a
first-class
problem
that
they
wanted
to
solve.
A
They
were
very
clearly
I,
think
bolted
on
later
and
and
do
not
fit
very
well
in
what
they
have
designed
so
with
tough
there's,
actually
different
ways
that
that
trust
replication
happens
in
the
system
and
because
of
this,
and
because
of
the
way
that
we
really
made
this
a
first-class,
primitive,
it's
so
natural
and
so
easy
to
do
that,
we've
actually
had
a
lot
of
people
want
to
copy
and
and
use
like
effectively,
toughs
trust,
revocation
and
other
domains
all
right.
So
another
thing
we
did
in
the
design
of
Toth
is
we.
A
It's
going
to
be
a
lot
harder
for
a
bad
thing
to
occur,
so
tough
uses
both
of
those
things
together
and
one
of
the
things
that
it
does
is
it
makes
it
so
that
there's
certain
very
sensitive
roles
in
the
system
that
have
to
do
things
like,
for
instance,
serve
as
a
route
of
trust.
Where
there's
a
series
of
keys
that
may
have
to
be
used
when
you've
had
a
serious
compromise
of
a
repository,
so
they
probably
only
get
used
every
six
months
or
so
in
normal
situations.
A
But
if
you
do
have
to
pull
them
out,
we
want
those
keys
to
be
able
to
be
stored
offline.
They
shouldn't
have
to
live
on
a
like
a
web
server
or
something
like
that.
So
tough,
very
much
supports
and
encourages
you
being
able
to
have
keys
that
are
sensitive,
be
things
like
you
bikies,
or
be
things
that
are
kept
in
safety,
deposit
boxes
or
safes
or
desk
drawers
or
things
rather
than
just
scattered
around
a
bunch
of
computers
connected
to
the
Internet
all
right.
A
And
finally,
one
of
the
things
that
happens
in
tough
is
because
of
our
use
of
something
called
delegations
which
I'm
not
going
to
go
into
a
lot
of
detail.
I'm
just
gonna
give
you
kind
of
a
feeling
about
what
what
it
does
for
you
is
that
in
tough
you
never
if
you're
using
tough
correctly,
you
should
never
ever
need
to
share
keys.
So
imagine
that
Bob
here
is
responsible
for
building
the
Windows
version
of
some
project.
A
I,
don't
know
some
fun
software
project
he
likes
and
some
intern
comes
and
wants
to
work
with
them,
and
the
intern
is
a
super
excited
Windows,
ME,
diehard
user.
So
Bob
knows
he
has
five
people
who
want
the
Windows
ME
version.
So
he's
like
ok,
intern.
You
know
I'm
gonna,
let
you
be
able
to
go
and
start
signing
the
ME
version.
A
So
the
way
you
would
do
this
in
if,
for
instance,
you're
doing
this
in
a
more
traditional
GPG
signed
way
that
Linux
distros
do
is
that
they
would
add
the
interns
key
to
the
keyring
for
the
distribution,
and
then
the
intern
could
sign
everything,
including
like
the
Linux
kernel
for
that
distribution.
Even
if
the
Linnet,
even
if
they're,
only
distributing
the
Windows
ME
variant
of
this
is
gotten
weird
cuz
if
we're
no
longer
in
a
Linux
distribution
land.
A
But
you
know,
even
if
the
intern
is
doing
like
Polish
language
translation
for
whatever
then
there's
their
key
would
be
trusted
for
everything,
and
so
by
the
other
option
is
that
Bob
just
goes
and
gives
the
intern
is
key,
which
would
also
be
terrible.
So
both
of
those
situations
are
really
bad
and
yes
can
lead
to
all
kinds
of
problems
when
something
goes
wrong,
all
right.
A
So
in
tough,
what
happens
is
that
in
tough,
the
intern
can
have
their
own
key
and
Bob
can
say:
hey
you
as
an
intern
you're
able
to
do
the
things
I
can
do,
but
only
in
this
way
only
for
this
specific
thing,
like
you,
can
only
sign
a
release
of
Windows
ME
you're
not
trusted
to
sign.
You
know
the
Windows
2000
release,
which
has
50
users
instead
of
5,
that
the
Windows
ME
release
has,
or
certainly
not
the
Windows
10
release
that
might
be
used
by
millions
of
people.
B
Right
thanks
so
I'm
going
to
talk
a
little
bit
about
what
you
would
do
to
set
up
tough
in
your
infrastructure.
So
if
you
wanted
to
use
this
in
your
system,
there's
a
couple
of
steps
to
get
this
done
this
you
have
to
do
a
little
bit
of
code
on
your
client
and
on
your
repository,
a
couple
of
steps
to
a
developer's
and
then
a
little
bit
of
extra
setup.
So
what
does
this
look
like?
So
on
the
client?
B
You
need
to
set
up
an
initial
view
to
trust,
so
tough
is
based
on
the
idea
that
the
client
has
this
initial
public
key
for
the
root
and
then
that
key
can
later
be
used
to
then
verify
updates
and
there's
a
lot
of
different
ways
to
get
this
key
on
to
the
client.
Initially,
you
can
use
any
public
key
infrastructure
system
that
maybe
your
system
already
uses,
or
you
can
do
a
trust
on
first
use
when
the
client
first
installs
the
software
before
any
updates
happen.
They
get
this
key
as
part
of
that
installation.
B
In
addition,
the
client
needs
a
verification
step.
They
need
to
actually
make
sure
they
verify
the
TUF
metadata
to
get
all
these
protections,
so
they
have
to
download
the
metadata
and
then
verify
it
before
installing
the
update
to
make
sure
that
they
don't
install
any
malware,
then
you
have
the
repository
which
basically
just
needs
to
generate
your
tough
metadata.
This
involves
a
couple
of
automated
processes
store
to
the
repository
they
need
to
be.
B
You
know,
like
the
code,
needs
you've
written
for
those
and
then
set
up
and
then
a
couple,
a
little
bit
of
manual
initialization
for
these
offline
roles.
They
can't
be
stored
on
the
repository
directly.
So
for
these
offline
roles,
you
have
your
developers
who
you
need
to
set
up
a
delegation
chain
initially,
so
your
delegation,
kitane
for
your
organization,
will
probably
look
a
little
bit
like
your
org
chart
like
you'll.
Have
you
know
your
head
engineer?
B
Is
your
you
know
your
your
first
like
the
route
of
the
delegation
and
then
they'll
delegate
to
the
heads
of
various
projects
who
maybe
will
delegate
to
their
team
members
depending
on
which
parts
of
the
projects
they're
responsible
for
and
then
you
also
have
the
route
keys,
which
these
are
those
offline
keys
that
you
wanna,
make
sure
are
very
secure?
And
so,
when
you
first
set
them
up,
you
want
to
make
sure
that
you
have
in
separate
locations.
B
So
there's
a
really
good
example
of
what
a
deployment
looks
like
in
practice
for
pi
PI.
This
is
an
ongoing
deployment,
but
it's
just
a
very
well
documented
example
of
how
this
process
will
happen,
and
so
there's
pet
458,
which
is
kind
of
a
more
basic
implementation
of
tuff
and
then
pep
480,
which
is
kind
of
the
full
implementation.
And
these
just
provide
a
lot
of
details
about
what
you
would
need
to
do
if
you
wanted
to
do
this
on
your
system.
B
Okay,
so
you
have
your
initial
setup
done.
So
what
do
you
need
to
do
to
maintain
your
system?
It's
pretty
much
just
two
things
you
have
to
do.
You
have
to
have
your
developer
sign,
update
and
do
a
little
bit
of
root
key
management.
Everything
else
should
be
automated
and
shouldn't
really
need
to
be
managed.
So
for
the
developer
side,
developers
need
to
use
those
keys
that
they
were
delegated
to
sign
updates.
This
is
really
similar
to
any
other
process
that
needs
to
have
signatures.
B
So
if
you
have
like
get
code
signing
or
anything
else
that
uses
GPT
keys,
this
is
a
very
similar
process
and
you
can
use
any
infrastructure.
You
already
have
like
any
UB
keys
that
developers
already
have
access
to.
In
addition,
you
to
maintain
that
she
and
a
developer
is
to
make
sure
that
the
keys
aren't
shared
and
that
if
a
new
developer
joins
the
team
either
their
key
is
delegated
to
or
a
50
developer
leaves
the
team
that
Keys
no
longer
has
access
to
the
system
etc.
B
And
then
you
have
a
little
bit
of
root
key
management.
So
this
should
only
happen.
This
shouldn't
be
a
big
overhead,
but
the
rookie
will
expire
after
some
period
of
time.
We
usually
recommend
like
about
six
months
or
a
year,
depending
on
your
use
case,
and
then,
when
that
key
experiment,
you
have
to
go,
find
those
offline
keys
and
use
them
to
sign
a
new
offline
keys,
which
will
then
continue
the
chain
of
trust.
Also,
if
there
is
a
major
compromise,
these
offline
root
Keys
can
be
used
to
recover
from
the
compromised.
B
So
this
is
like.
The
maintenance
you
don't
have
to
do
is
basically
all
the
other
parts
of
tough.
So
the
repository
actions
are
completely
automated,
so
after
you're
signed
code
is
uploaded,
the
repository
will
automatically
do
the
other
signing
and
then
it'll
be
sent
to
the
client.
Who
will
automatically
do
the
verify?
So
this
you
really
after
your
first
set
it
up.
You
don't
really
have
to
worry
about
this
part.
B
So
once
you
have
this
all
in
place,
you
get
a
lot
of
security
guarantees,
and
so
this
is
kind
of
shows
if
you're
able
to
install
malicious
update.
If
any
of
these
things
are
compromised.
So,
as
you
can
see,
a
root
key
compromise
is
very
bad.
That's
kind
of
the
main
problematic
one
of
this.
This
chart,
however,
less
than
a
threshold
of
root
Keys
is
not
as
much
of
a
problem.
B
So
what
this
means
is
that
you
want
to
make
sure
that
your
root
key
threshold
is
large
enough,
that
you
never
get
to
that
bottom
row.
You
only
ever
get
to
that
they've
ever
wound
up
and
they
were
able
to
revoke
those
compromise
keys.
In
addition,
if
both
your
repository
and
a
developer
are
compromised,
they
like
an
attacker
would
be
able
to
install
malicious
updates,
but
only
for
that
developers
project
and
then
the
root
rule
could
go
in
and
revoke
those
keys
after
some
amount
of
time.
B
So
that's
all
the
things
that
tough
does
protect
you
against
these
are.
These
are
some
things
that
are
kind
of
out
of
scope
of
the
project
or
some
things
that
we
leave
flexible.
So
tough
does
not
supply
a
do
supply
chain
security,
so
tough
kind
of
manages
the
part
after
your
code
is
already
it's
already
finished.
So
you
already
built
your
code.
It's
ready
to
be
sent
to
your
customers
so
from
there
to
the
to
the
client.
B
That's
the
part
that
tough
manages,
like
all
the
stages
before
that
are
just
kind
of
out
of
scope
for
the
project,
and
there
are
lot
of
other
really
good
projects
that
you
can
look
at,
such
as
in
todo
or
other
projects
for
the
rest
of
the
supply
chain.
So,
if
also
doesn't
manage
that
initial
root
of
trust
and
I
touched
on
this
a
little
bit
earlier,
but
you
have
to
have
some
other
way
to
get
that
initial
root.
Public
key
to
the
clients
and
tough,
also
doesn't
force
any
deployment
decisions.
B
So
we
have
a
reference
implementation
of
tough
that
provides
a
lot
of
this
functionality.
But
if
you
have
for
your
system,
you
have
specific
requirements,
you
could
design
a
version
of
tough
to
meet
those
requirements.
For
example,
the
reference
of
invitation
uses
JSON
metadata
formats,
but
if,
for
some
reason
you
have
other
metadata
formats
that
we
work
better
for
your
system,
you
can
still
use
this.
You
can
still
use
tough
with
using
those
metadata
formats.
B
In
addition,
your
key
storage
and
thresholds
are
up
to
you
and,
and
they
trade
offs,
that
your
organization
wants
to
make
so
stuff
is
used
in
production
by
a
lot
of
different
people.
We
have
a
bunch
of
different
deployments,
so
we
have
our
reference
of
notation
deployment,
which
is
used
by
some
people.
B
B
In
addition,
notary
is
an
implementation
which
I
think
is
written
and
go,
and
that
also
is
available
in
github
if
you
want
to
contribute
and
become
a
part
of
that
project
or
if
you
want
to
add
tough
to
your
project,
if
you
provide
updates
to
people-
and
you
want
to
make
sure
that
they're
secure,
you
can
add
tough
and
talk
to
us
about
how
to
get
that
going
say.
Thank
you
and
let
us
know
if
you
have
any
questions.
A
A
Yeah,
okay,
so
really
anywhere,
where
you're
trying
to
deliver
software,
that
you
want
to
make
sure
that
software
was
not
tampered
with.
Sorry,
sorry,
let
me
repeat
the
question
so
when
and
where
should
you
deploy
top
anywhere
where
you're
trying
to
distribute
software-
and
you
don't
want
that
software
to
be
tampered
with
you
you,
you
know
that
would
be
bad.
You
should
be
using.
A
Tough
is
really
the
answer,
even
in
cases
where
you
know-
and
this
is
outside
the
cognitive
space
too
like
we
have
integrations
and
are
there's,
you
know
work
with
a
bunch
of
other
communities.
Python
was
mentioned,
but
there's,
but
you
know
bunch
of
other
large
communities
like
that
that
are
doing
work
in
a
great
tough.
A
This
really
is
I,
think
I
believe
we're
the
only
system,
that's
open,
that
provides
any
kind
of
compromise,
resilience
and
I've
done
work
under
NDA
with
some
very
large
companies
that
also
use
basically,
what
is
tough,
with
slight
changes
to
it
to
fit
their
environment.
So
this
is
definitely
what
you
should
be
doing,
instead
of
TLS
or
GPG,
because
once
again,
if
somebody
breaks
into
your
server
or
breaks
into
your
build
system,
that's
how
your
logo
ends
up
on
the
first
quiz
slide
that
I
had
so,
and
nobody
wants
that.
C
A
Okay,
so
I
think
I
think
the
question
you're
asking
is
more
of
a
doctor
secrets,
question
I,
think
what
you're
asking
is.
Is
that
should
you
have,
should
you
deal
with
secret
management
in
different
way
in
different
AWS
regions,
for
instance?
In
case
you
have
a
compromise
so
that
information
doesn't
flow.
A
To
answer
your
question
first
directly,
let
me
let
me
say:
I
didn't
directly
work
on
doctor
secrets
or
a
lot
of
the
other
like
hash
record
vault
or
the
other
competitors
to
it.
So
I
believe
there
is
some
value
and
what
you
say,
but
I'm,
not
really
an
expert
I
will
say
from
the
standpoint
of
tough
what
the
client
has
is.
It
has
public
keys
for
the
repositories
and
things
that's
going
to
be
communicating
with.
So
from
that
standpoint,
it's
not
like
the
client
has
any
sensitive
key
material.
A
D
A
So
how
does?
How
does
tuff
differ
from
dr.
secret's
fault
and
other
things
like
that?
So
they
do
secret
management,
so
they're
meant
to
do
things
like,
for
instance,
make
sure
that
you
don't
type
in
passwords
and
private
keys
for
encrypted
databases
and
stuff,
like
that.
You
know
that
that
that
information
securely
gets
to
your
containers
and
it
is
provisioned
tuff-
is
making
sure
the
actual
software
that
gets.
There
is
like
the
actual
image
that
you
get
wasn't
tampered
with.
Okay,
so
like
vault,
in'
and
other
things
like
this
are
protecting
secret
data.
A
Tuff
is
not
protecting
secret
data.
It's
bootstrapping
your
software,
which
is
usually
public
data
that
you're
gonna
go
like
your
software
images,
so
there's
no
vault
on
there's
no-one
sealing,
there's!
No
anything
like
that
that
you
would
typically
have
in
those
in
those
cases
and
there's
also
no
real
compromised
resilience
in
the
same
way,
because
it's
it's
like
a
different
space.
Yes,
in
the
back.
E
A
So
then
to
do
exactly
what
you're
describing,
which
is
to
make
sure
this
doesn't
happen,
and
this
whole
sort
of
pipeline
is
actually
already
being
used
today
in
production
by
thousands
of
companies,
and
so
it's
kind
of
ready.
You
know
off
the
shelf
with
a
couple
different
implementations
and
integrations,
although
I
think
we're
gonna
be
focusing
on
the
Debian
one
in
the
in
the
talk.
But
we
can
also
tell
you
there's
a
lot
of
public
information
about
the
large
data
dog
integration
and
others
like
that.
That
that
do
this.
A
A
Are
there
other?
Are
there
other
package
managers,
perhaps
at
the
language
level
or
the
OS
level
that
we're
talking
to
about
using
this?
The
thing
about
the
open
source
community
is
you're,
always
talking
to
everybody,
whether
you
mean
to
or
not
so
we
are
having
discussions
and
we
have
had
discussions
actually
aptiom
yeah
stand
pacman
all
use
a
security
design
that
I
did
as
part
of
my
dissertation
work
right.
A
So
we've
had
a
lot
of
those
engagements
and
in
fact
what
was
interesting
is
our
discussions
with
pipey
I
took
place
like
six
seven
years
ago,
or
something
like
that.
We
did.
We
standardized
some
of
the
things
we
wanted
to
do
through
the
pet
process
and
then
docker
saw
this
and
got
very
interested
and
just
kind
of
picked
it
up
and
ran
with
it,
because
a
lot
of
people
heard
about
it
in
part
through
people
in
the
Ruby
community
that
were
very
interested
in
using
it.
A
So
the
community
is
all
very
connected
and
yes,
there's
a
lot
of
interest,
but
it's
also
one
of
these
things
that
we
found
that
until
you
know,
until
the
thing
is
in
production,
you
often
get
like
the
checks
in
the
mail
kind
of,
as
you
talk
to
people
about
how
they're
going
with
your
integration,
so
I
don't
want
to
count
any
chickens.
But
yes,
we
there
are
things
that
are
definitely
emotion
and
encode
is
happening.
In
fact,
Amazon
just
about
a
week
ago
released
an
open-source
implementation
of
tuff
and
rust.
A
We
I,
there's
I,
will
know
more
about
that
tomorrow,
I
there's,
you
have
to
catch
up
with
some
of
the
people,
so
there's
some
people
that
were
in
the
know
that
were
that
are
like
kind
of
in
the
notary
project
and
things,
but
in
the
core
of
tough,
because
tough
itself
is
aspect
to
that.
A
lot
of
people
implement
that
we
encourage
that
to
happen,
and
so,
as
a
result,
the
information
doesn't
necessarily
flow
all
the
way
back
to
us
very
quickly.
If
at
all,
so
yes.
A
Yeah,
what
do
we
think
about
enforcing
tough
on
admission
control,
yeah,
I
I?
Think
that's
great
I
think
you
know
it's
you,
you
obviously
having
better
integration
into
tough
to
check
and
verify
that
things
are
being
done
in
the
right
way.
It
really
just
protects
you
I
mean
it
protects
you
so
that
you
don't
run
into
situations
where
you
know
so
so
yeah
one
thing
marina
said
that
I
just
want
to
kind
of
reiterate
to
kind
of
answer.
A
This
question
is:
is
that
tough
is
basically
completely
silent
to
your
users
unless
something
terrible
has
happened,
and
then
they
get
this
error
and
it
says:
hey
something
you
know
like
this.
Signature
doesn't
match
anymore.
You
know,
what's
what's
going
on
here
too,
you
know,
looks
like
someone
might
have
hacked
docker
hub
or
something
like
that.
You
know
and
that's
exactly
what
I
think
you
want
to
do
and
so
doing
those
checks
in
the
right
places
for
your
environment
is,
is
really
critical
and
even
further
to
do
an
even
better
job
of
this.
A
B
I
think
basically
he's
asking
like
these:
are
the
requirements
to
the
metadata
and
I
think
the
answer
is
yes,
there's
certain
certain
fields
that
we
require
as
part
of
tough,
to
be
part
of
the
different
metadata
files,
sorry,
okay
and
then
those
sorry,
those
required
fields
are
then
used
as
part
of
the
verification
process,
and
you
can
add
your
own
custom
fields.
If
you
have
additional
things,
you
need
to
check.
F
A
I
see
I
get
I
get
more
your
question
now.
Okay,
so
tough
in
its
metadata
basically
says
something
like
this
object
with
this
sort
of
name
you
can
think
of
it,
which
is
something
that
then
whatever
tool
you're
using
to
actually
do
the
request
and
do
the
you
know,
do
the
actual
installation
can
go
and
and
request
that
object,
which
in
many
cases
is
like
a
URL
or
something
like
go,
go,
get
this
thing,
and
then
it
has
something
like
a
secure
hash,
so
something
it
can
check
for
that
object
that
it
gets
back.
A
There
are
other
fields
that
are
optional,
that
you
can
put
there's
like
the
ability
to
put
whatever
metadata
you
want
there.
It's
not
like
an
opinionated
structured
thing
like
you
would
find
in
graffia,
Saur,
SP,
DX
or
software
build
materials
or
whatever,
where
you
have
to
have
like
these
seventeen
fields
that
indicate
all
this
type
of
provenance
and
whatever
else,
because
that
differs
wildly
by
different
domains
and
use
cases
and
so
on.
A
But
tuff
has
space
for
you
to
put
whatever
you
want,
for
instance,
in
todo
metadata,
as
you
know,
or
in
the
case
of
the
you
know,
the
large
automotive
companies
that
are
using
it.
They
go
and
they
insert
a
bunch
of
information
about,
like
which
VIN
and
which
EC
occu
serial
numbers
and
other
things
like
that.
This
specific
update
would
apply
to.
A
Okay,
so
there's
a
lot
on
that
question
and
I'll
try
to
I'll
try
to
rephrase
it
in
a
way
that
I
can
actually
answer
it.
This
is
well
okay,
so
it
was
good.
It
was
a
good
question,
but
there's
some
parts,
I'm
I'm
gonna
kind
of
duck
a
little
bit
here.
So
have
you
spoken
with
regulators
and
different
agencies
about
this?
What's
their
view
on
something
like
tough?
How
do
they
perceive
it?
Are
there
you
know?
Is
it
something
where
you've
gotten
some
folks
to
bless
it
and
then
right?
A
And
we
have
done
that
in
some
areas
we
have
been
more
focused
because
the
tough
variant
obtained
is
actually
used
by
major
OEMs
in
the
United
States,
multiple
major
OEMs,
United
States,
multiple
major
OEMs
in
Japan
and
multiple
major
OEMs
in
Europe,
so
they're,
very
aware
of
it,
and
we've
also
made
strides
with
many
other
communities.
There
are
folks
specifically
in
finance,
since
you
brought
up
finance
as
part
of
your
question
that
are
using
tough
in
different
ways.
A
We
would
be
happy
to
engage
with
regulators,
and
do
things
like
this
tough
is
is
by
the
way.
There's
not
a
company
directly
backing
tough,
like
I,
make
zero
dollars
for
every
tough,
install
and
and
every
everything
with
it,
there's
no
like
paid
subscription
plan
for
whatever
or
anything
else
happen.
I'm
a
university
professor
right.
A
So
the
goal
is
to
make
the
world
a
better
place
and
Finance
is
an
important
place
to
make
better,
and
so,
if
we
need
to
spend
time
talking
to
regulators
well,
NYU's
in
new
york,
there's
an
awful
lot
of
finance
happening
around
there.
I
go
to
DC
a
lot
too
happy
to
talk
with
people
and
happy
to
do
what
I
can
to
educate.
A
G
A
A
What
to
install
right-
and
this
combination-
and
this
like
threshold
delegation
between
them,
has
meant
that
even
if
a
nation-state
actor
goes
and
becomes
a
man-in-the-middle
breaks
in
to
their
server
with
the
online
key
or
you
know
and
steals
all
of
the
the
keys
on
it,
some
of
which
you
know
right.
It
would
be
protected
and
breaks
into
the
vehicles
network
through
something
like
their
infotainment
unit.
A
Then
the
damage
they
can
cause
is
something
like
saying
that
there
hasn't
been
an
update
for
the
last
week
when
there
has
been
one
they
in
addition
to
that,
they
also
have
to
go
and
break
in
and
steal
either
the
route
signing
keys
or
break
in
and
steal
offline
keys
for
the
other
server,
which
are
often
located
around
the
world,
which
starts
to
sound
a
lot
more
like
Ocean's,
eleven
or
something.
Then,
then,
even
what
you
know,
these
very
talented
nation-state
actors
are
are
able
to
do
so.