►
Description
A Series of Lightning Talks from CNCF Project LeadsVirtual Experience
There’s considerable interest to leverage TEE capabilities from cloud-native projects, such as SPIFFE, Notary, Sigstore and Parsec, which each address separate concerns within the CNCF. In this talk, leaders from these projects will describe how they use hardware-based trust today to enhance cloud native workloads, and ways that we can improve security with new capabilities enabled by TEE’s in the future. This session will be moderated by Aeva Black.
Talks to be included:
sigstore, Software Signing for the Masses, presented by Luke Hinds: sigstore is a new project launched under the Linux Foundation to provide a free to use, non profit code signing service. Project founder Luke Hinds will provide an introduction to the project.
To learn more about the Confidential Computing Consortium, a community focused on projects securing data in use and accelerating the adoption of confidential computing through open collaboration see: https://confidentialcomputing.io/
A
A
A
We've
been
working
in
this
domain
for,
like
I
say,
almost
a
year,
but
things
have
really
come
to
a
head
now,
and
so,
especially
with
this
executive
order,
so
everybody's
running
around
trying
to
find
s-bombs
and
trying
to
find
what
various
solutions
there
are
and
six
or
is
focused
on
solving
part
of
this
problem.
Okay,
because
it's
a
large
problem
space,
there's
a
there's,
many
heads
to
this
beast
so
we're
we're
tacking
one
around
software
signing
which
I'll
go
into
shortly.
A
A
Others
have
keys
that
are
stored
on
websites
or
github.
Repos.
Read
me
sorry
and
one
that
we've
actually
changed
recently
is
kubernetes,
so
we
recently
onboarded
them,
but
most
of
these
projects
we
we're
actually
talking
to
and
we're
looking
to
to
introduce
them
to
using
our
sign-in
system,
which
we'll
go
into
shortly.
It's
the
same
thing
with
package
managers,
some
of
them
have
systems,
but
users
don't
use
them
at
all.
Others
have
very
good
adherence
okay,
others
have
nothing
at
all.
So,
for
example,
you'll
see,
there's
crates,
dot
io.
A
So
one
of
the
great
things
about
rust
is
you
obviously
get
very
good
safety
guarantees
around
the
the
compilers
enforcement
of
ownership
and
so
forth,
but
everything
that
you
pull
down
is
not
signed,
so
you're
running
unsigned
code
at
system
level.
So
so
you
know
these
are
same
with
you
know:
ruby
they
have
a
form
of
signing,
but
nobody's
actually
signing
much
about.
Two
percent
of
people
are
signing
things
at
the
moment.
A
So
it's
a
very
spotted
picture
and
it's
it's
not
a
particularly
great
picture
as
well,
so
just
a
kind
of
a
very
you're
as
you're
a
security
centric
group
of
people.
So
I
imagine
this
is
probably
common
knowledge
to
you,
but
what
to
sign
in
provide,
so
we
can
verify
the
integrity
of
content
so
that
any
particular
content
is
tampered
with
or
changed
to
one
bit
then
that
sort
of
throws
out
the
integrity
non-repudiation.
A
A
Then
you
can
assume
the
identity
of
that
particular
assignee
and
if
there's
some
time
stamps,
then
you
have
guarantees
around
when
that
signing
event
occurred.
Now
the
problem
is
that
for
a
lot
of
people,
managing
private
keys
is
a
challenge
because
it's
expensive,
you
know,
if
you
consider
you
have
somebody
like
somebody.
That's
running
maintains
a
a
node
js
project,
okay
in
their
in
their
spare
time,
and
they
can't
afford
to
buy
a
ub
key
and
they
don't
want
to.
A
A
A
So
if
we
look
at
the
people
do
implement
it,
it's
a
very
it's
a
picture
that
could
certainly
do
with
improving
okay,
and
so
we
came
up
with
six
store.
Okay
and
sigstor
is
it's
a
project
under
the
linux
foundation
and
it's
a
collection
of
projects
that
can
be
deployed
independently
or
together,
provide
the
infrastructure
to
provide
software
signing
and
transparency,
so
under
the
linux
foundation.
A
We're
looking
to
launch
this
as
a
public
good
service,
so
plans
are
underfoot
at
the
moment
to
to
do
that
and
we're
very
much
basing
this
on
the
let's
encrypt
model.
Okay,
but,
as
I
say,
all
of
this
stuff
could
be
run
behind
a
firewall,
so
you
could
stand
all
of
our
infrastructure
up
within
a
sort
of
corporate
network
and
use
it
to
sign
artifacts
and
so
forth,
so
kind
of
a
quick
decoder
of
the
projects
we
have
full
seo.
This
is
our
rca,
our
web
pki,
and
this
provides
code.
A
A
So
transparency
logs
I'm
going
to
whiz
through
this
quickly,
but
if
anybody's
not
familiar
with
them,
they're
basically
built
on
a
technology
called
a
merkle
tree.
So
it's
these
leaves
of.
Hashes
are
concatenated
together
until
you
arrive
at
eventual
root
hash
and
that
root
hash
represents
the
the
integrity
state
of
the
entire
tree.
Okay,
so
you
can
then
do
these
you
can
compute
these
things
called
inclusion
proofs.
So
I
can
check
that
a
particular
data
set
that
I
have
that
is
in
the
tree.
A
Its
integrity
is
sound.
Nobody
has
tried
to
tamper
with
that,
because
if
anybody
tries
to
tamper
with
this,
it's
like
a
hash
extend
function.
It
breaks
the
computational
structure
of
the
entire
tree.
Okay
and
the
good
thing
about
these
transparency
logs
they're
openly
auditable.
So
we
run
our
transparency
log
in
the
public.
So
other
people
can
monitor
it
and
and
make
sure
that
there's
nothing
on
toward
happening
with
the
transparency
log.
A
So
this
is
our
quite
sort
of
complex
architecture.
Okay,
so
I'm
not
going
to
try
and
walk
through
this
now.
What
I'm
going
to
do
is
going
to
do
a
very,
very
quick
overview
of
how
this
plays
out.
So
we
have
our
user
a
developer.
They
got
some
sort
of
artifact.
They
want
to
sign
a
container
or
blob
an
s-bom,
a
tab
or
whatever
they
may
be.
We
have
our
web
pki.
A
So
this
is
the
full
co
project
and
we
have
two
transparency
logs:
a
certificate,
transparency,
log
and
a
signature,
transparency
log
and
what
occurs
is
the
developer
generates
a
key
pair.
So
these
are
ephemeral.
These
don't
even
touch
the
disk.
We
encode
these
to
memory
because
the
the
the
idea
is
that
these
are
going
to
be
short-lived.
A
Now
the
user
will
using
the
public
key.
They
will
they're
sort
of
using
their
key
pair.
They
will
send
a
challenge
effectively
to
our
web
pki,
okay
and
then
our
web
pci
will
respond
back
with
a
an
open
identity
grant
session
screen.
Okay,
so
they
can
click
on,
they
have
an
account
github
or
google
or
twitter
or
whoever
they
can
select
that
and
then
what
will
happen
is
if
that
passes.
A
So
I've
got
okay,
google
going
off
in
the
background.
If
that
passes,
what
will
happen?
Is
the
an
x
509
certificate
will
be
sent
to
our
certificate
transparency
log?
This
will
contain
the
email
and
that
we
got
from
the
idp,
not
the
one
from
the
user.
Okay,
the
the
challenge
is
simply
to
to
fix
the
identity
of
the
user
to
the
public
key
pair
okay,
and
this
is
time
stamped
as
well.
Now,
after
that's
happened,
the
certificate
is
returned
back
to
them
that
they
can
then
use
to
sign
with.
A
A
We
don't
have
to
worry
about
storing
those
securely
and
worry
about
revoking
them,
they're
gone,
because
what
we
now
have
is
a
trust
route,
so
using
the
two
transparency
locks
and
the
key
pair,
that's
associated
between
them
and
some
time,
stamping.
We
then
know
that
an
individual
in
charge
of
an
identity
provider
account
signed
a
particular
digest
at
a
particular
time.
Okay,
so
we
then
have
guarantees
that
whoever
is
in
charge
of
this
account.
A
Okay,
so
my
own
account
had
a
public
key
pair.
They
signed
something
and
they
generated
a
signature,
and
we
had
this
trust
route.
That
said
in
these
immutable
transparency
logs-
and
this
then
gives
us
guarantees
that
this
identity
sign
this
now
accounts
can
be
compromised,
of
course,
but
the
nice
thing,
then,
is
we
have
it
in
the
transparency
log,
because
if
it's
not
in
the
transparency
log,
you
don't
trust
it
effectively.