►
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.
Securing Container Delivery with TUF - Lukas Puehringer, NYU
One of the most pressing security problems in cloud native is the secure delivery of container images. Common solutions addressing this problem live under the assumption that a signing key, used to protect an artifact or its distribution, is kept safe. But time has shown again and again that this assumption is faulty, and that a single key loss or compromise can cause enormous damage. That is why The Update Framework (TUF) was designed not only to prevent and detect attacks, but also with risk mitigation (reducing the damage from a successful attack) as a core principle. Being the first security-focused project to graduate in the CNCF, TUF is widely used both in and outside of the cloud ecosystem. In this talk we will describe the basic architecture of TUF including how TUF protects against a variety of real-world attacks on any software distribution infrastructure. We will show how even if an organization makes a security error (a server is hacked, a private key is checked into github, etc.), TUF can bring a repository back into a secure state.
https://sched.co/ZexA
A
A
A
Entoto
does
so
by
creating
a
verifiable
trace
from
the
first
lines
of
code
until
deployment
or
installation
and
taft
takes
care
of
the
delivery.
So
the
real
difference
between
those
two
frameworks
is
the
region,
the
supply
chain,
where
they
operate
on
today,
we're
going
to
look
at
top.
As
I
said,
tough
takes
care
of
delivery
so
that
the
software
comes
to
the
client.
A
The
client
may
be
a
person
who
installs
a
binary
package
from
his
or
her
programming
language
package
manager,
but
it
can
also
be
a
server
that
is
a
containerized
image
for
production,
but,
let's
so
tough
really
works
with
any
existing
infrastructure.
It's
really,
to
put
it
very
in
a
very
simplified
way.
It's
really
just
a
bunch
of
metadata
files
and
cryptographic
keys
and
the
knowledge
how
to
modify
those
files
and
sign
them
on
the
server
and
how
to
interpret
and
verify
them
on
the
client.
A
A
A
A
So
we
do
need
to
have
a
plan
p,
a
plan
b
for
when
a
compromise
happens,
a
very
natural
approach
for
many
would
be
to
just
sign
it.
There
are
a
couple
of
common
approaches.
One
would
be
to
assign
the
communication
channel
using
transport
layer
security,
which
is
really
great
for
protecting
against
men
in
the
middle
attacks,
but
the
problem
is
that
tls
heavily
relies
on
a
single
key.
So
if
a
if
an
attacker
breaks
into
the
server,
then
they
can
serve
you
whatever.
They
want
I'll
bite
over
a
secure
channel.
A
So
even
if
you
regularly
go
to
key
signing
parties,
which
I'm
sure
you
all
do,
then
how
do
you
know
which
key
is
authorized
to
provide
signatures
for
which
package?
And
how
do
you
encode
such
things
as
signature
thresholds,
where
you
want
multiple
signatures
from
different
keys
to
provide
to
provide
guarantee
for
a
package?
A
A
A
A
Separating
responsibilities
also
allows
us
to
to
give
different
weights
to
different
responsibilities.
For
instance,
high
impact
responsibilities
get
very
secure
offline
keys.
On
the
other
hand,
if
we
need
online
keys,
for
instance
due
to
availability
concerns,
then
we
give
them
low
impact
responsibilities.
A
Another
mitigation
technique
to
reduce
the
impact
of
a
compromise
are
signature
thresholds.
I
mentioned
this
earlier
when
I
talked
about
gpt,
it's
a
little
bit
like
having
different
keys
for
different
responsibilities.
Even
within
one
responsibility,
we
can
encode
thresholds
in
tough
to
say
for
this
responsibilities.
I
want
and
different
signatures
from
different
keys.
A
So
these
are
all
techniques
to
mitigate
the
impact
of
a
compromise,
and
another
thing
that
tough
has
built
in
in
its
core
design
is
the
way
to
recover
from
a
compromise
when
a
key
is
lost
or
stolen.
We
need
a
way
to
tell
our
clients
to
not
use
that
key
anymore
and
instead
use
a
different
one
and
taft
has
ways
to
do
explicit
and
implicit
key
replication.
A
A
There
are
four
of
them:
there
is
the
targets
role
which
takes
care
of
the
integrity
of
target
files
in
tough
surgon.
We
call
target
files,
the
application,
binaries
or
container
images
or
any
file
really
that
we
are
interested
in
that
we
want
to
update,
and
there
is
a
specific
role
for
that.
That's
dedicated
to
guarantee
their
integrity.
A
Then
there
is
the
snapshot,
role,
taking
care
of
consistency
of
the
overall
repository,
the
timestamp
role,
taking
care
of
freshness
and
a
root
role
that
that
takes
care
or
that
that
serves
as
the
root
of
trust.
For
all
of
these
roles,
these
roles
all
probably
look
nice
and
reasonable,
but
also
quite
abstract,
at
least
when
I
first
started
to
work
on
tough.
It
was
hard
for
me
to
extrapolate
to
to
how
this
really
looks
in
code
and
in
an
implementation
in.
A
I
already
said
this
earlier
that
it's
just
a
bunch
of
metadata
files
and
in
a
very
oversimplified
way.
This
is
true,
so
for
each
of
these
roles
in
tough,
you
have
a
specific
metadata
file
for
a
targets
file.
You
have
target
submitted
for
the
targets
role.
You
have
targets
metadata
for
the
snapshot
role,
you
have
snapshot
metadata
and
so
on.
A
First,
let's
take
the
targets.
Metadata
targets.
Metadata
is
responsible
for
the
integrity
of
target
files.
I
said
this
earlier.
It
does
so
by
listing
each
of
the
target
files
on
the
repository,
for
instance.
Here.
In
this
example,
we
have
the
python
package
beautiful
soup,
which
helps
you
to
parse
html
pages
and
to
protect
its
integrity.
It
lists
its
hash.
A
A
A
A
Here
we
only
have-
or
it
does
so
by
list
listing
the
latest
version
of
the
target's
metadata
in
the
repository
in
this
example,
we
only
have
one
targets
metadata
file
listed
here,
but
usually
or
in
real
world.
There
are
often
more
targets
metadata
files
to
encode,
complex
trust,
delegations
which
are
a
bit
out
of
scope
for
this
talk,
but
having
all
these
targets
metadata
files,
an
attacker
won't
be
able
to
serve
an
inconsistent
state
even
with
maybe
benign
different
versions
of
of
packages
that
together
break
the
client.
A
A
A
So
a
client
won't
be
able
to
launch
a
freeze
attack
where
an
attacker
won't
be
able
to
launch
a
freeze
attack
where
they
trick
the
client
or
make
the
client
believe
that
there
are
no
more
updates
and,
as
we
saw
earlier
in
this
in
this
slide
about
the
ios
update,
all
software
is
often
vulnerable
software.
So
it's
important
to
always
keep
our
client
to
always
inform
our
client
about
new
updates
a
similarly
a
similar
attack
is
the
rollback
attack.
Timestamp
uses
a
a
version
number
for
itself
to
protect
against
that.
A
That's
when
an
attacker
serves
an
older
metadata
file
than
the
current
one
that
might
not
have
yet
been
expired,
and
to
protect
against
that
we
have
a
strictly
incrementing
version
number
and
time
stem
and
also
in
the
other,
metadata
files
for
redundancy.
I
left
this
out
to
keep
it
brief
and
simple
here,
but
the
idea
is
to
only
allow
higher
version
numbers
whenever
we
update
a
metadata
file
and
last
but
not
least,
we
have
the
root
metadata
file.
A
A
Only
the
public
portions
of
those
asymmetric
keys,
of
course,
and
the
client
can
use
these
keys
to
verify
the
metadata,
furthermore
lists
it
has
an
entry
for
each
of
the
roles
here.
I
only
show
targets
role,
but
it
also
has
an
entry
for
snapshot
times
then
stamp
and
root
itself,
where
it
maps
the
keys
from
the
key
store
to
the
role
by
an
id,
and
it
also
defines
a
signature
threshold
so
for,
for
instance,
in
this
example,
we
require
at
least
two
valid
signatures
for
targets
metadata
using
any
of
the
key
ids
defined
here.
A
So
if
the
key
is
compromised-
and
we
talked
about
this
earlier-
this
happens-
if
the
key
is
compromised,
then
we
just
need
to
update
the
root
metadata,
add
a
new
key
to
it,
to
the
key
store
and
replace
the
assignment
in
the
role
entry.
So
here
we
just
remove
the
old
key
id
for
that's
authorized
to
provide
signatures
for
the
targets,
role
and
add
the
id
of
the
new
key.
This
is
called
explicit.
Revocation
this
even
works
for
the
root
metadata
itself.
A
A
We
at
new
york
university
host
a
reference
implementation,
that's
written
in
python,
and
it's
also
used
in
production
at
datadog,
and
then
there
are
plenty
of
other
implementations
in
other
languages
that
are
used
for
other
tough
adoptions.
There
is
a
implemented
an
implementation
in
rust.
There
is
an
implementation
in
go.
I
think
there
is
also
one
in
ocam
and
yeah.
They
are
used
by
various
organizations
to
secure
the
updates.
A
A
A
That's
a
standards
document
describes
how
to
use
stuff
with
the
python
package
index
and
we,
the
python
software
foundation,
has
received
funds
to
make
this
happen,
and
we
nyu
are
helping
to
update
our
reference
implementation,
which
somehow
forces
us
to
revise
some
of
our
concepts
and
add
a
couple
of
usability
enhancements
and
also
performance
optimizations,
which
is
really
great
and
we're.
Also
adding
new,
exciting
features
to
our
reference.
Implementation,
such
as
the
ability
to
sign
with
hardware
security
modules
or
using
cloud
storage
for
metadata,
and
so.
A
There
are
also
links
to
the
software
source
code
repository
on
github.
It's
all
open
source.
What
we
do,
please
also
sign
up
to
our
mailing
list.
It's
very
low
traffic,
but
we
announce
our
our
monthly
community
community
meetings
there,
where
everyone
was
interested
in
tough
or
things
that
tough
might
be.
A
good
addition
to
their
infrastructure
is
welcome
to
join.
A
A
In
particular,
I'd
like
to
thank
joshua
locke
from
vmware,
who
has
been
a
lot
of
help
lately
in
making
enhancements
to
the
reference
implementation
of
tough
I'd,
also
like
to
make
a
quick
announcement
that
santiago
torres
will
be
giving
a
talk
about
in
toto
in
an
hour
here
in
virtual
kubecon,
so
make
sure
to
check
that
out
too
and
yeah
stick
around
for
the
virtual
q
and
a
and
talk
to
you
in
a
bit.
Thank
you.