►
From YouTube: Trust No One: Bringing Confidential Computing to Containers- Samuel Ortiz, Intel & Eric Ernst, Apple
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.
Trust No One: Bringing Confidential Computing to Containers - Samuel Ortiz, Intel & Eric Ernst, Apple
Today’s containers run in wildly heterogeneous environments. When deployed on multi-tenant clouds, they can span across nodes, regions, and multiple Cloud Service Providers (CSPs) while sharing CSP-owned resources between tenants. In such hostile environments, protecting containers data and code requires full trust on the CSP stack. Confidential computing leverages emerging hardware technologies to build Trusted Execution Environments (TEE) that protect cloud code and data at rest, in transit and in use, allowing tenants to trust no one but themselves. In this presentation, we will describe cloud native gaps for supporting confidential computing through memory encryption, authenticated launch and application attestability. Attendees will learn how secure container runtimes like Kata can close those gaps and leave with a proposed software architecture to bring confidential computing to cloud native workloads.
A
This
is
very
appealing.
These
essentially
completely
remove
the
host
software
stack
from
the
guest
ecb,
including
the
host
firmware,
the
kernel,
the
hypervisor
everything
is
out,
and
the
interesting
part
of
this
is
that
the
tenant
is
the
only
one
that
can
see
and
modify
its
data.
No
one
else
can
see
it;
no
one
else
can
can
modify
it
and,
most
importantly,
the
infrastructure
owner
the
csp,
the
the
the
infrastructure
provider
does
not
need
to
be
trusted
anymore.
So
this
is
a
very
interesting
threat
model.
A
How
do
we
get
there?
What
needs
to
be
provided
by
those
computing
computational
computing
technologies
to
build
that
threat
model?
Well,
the
first
thing
is
that
the
they
need
to
protect
the
tenants
data.
This
is
this
is
obvious.
I
think,
if
you
don't
want,
if
you
want
to
remove
the
whole
software
stack
from
from
the
guest
tcb,
you
want
to
make
sure
that
the
host
software
cannot
see
or
tamper
with
the
guest
data
and
the
tenants
data,
but
that's
not
enough.
A
So,
first
we
want
computational
computing
technologies
to
protect
our
data,
and
we
kind
of
we
can
already
do
that.
Our
data
can
be
in
three
different
states.
It
can
be
in
transit
that
is
typically
where
your
data
is
is
going
through
some
networking
pipes
and
we
have
tls.
We
have
vpns
in
when,
when
our
data
is
in
that
state,
it's
it's
basically
protected.
We
know
how
to
do
this
same,
for
when
the
data
is
addressed,
which
means
it's
it's
stored
somewhere.
We
have
disk
encryption.
A
I,
in
order
to
not
trust
the
software
components
coming
from
the
host.
I
want
to
be
able
to
not
only
protect
my
data
and
make
sure
that
my
infrastructure
owner
cannot
see
or
tamper
tamper
with
it,
but
I
also
want
to
be
able
to
verify
that
the
software
stack
that
I'm
running
inside
my
guest
is
the
one
I'm
expecting
to
to
be
running
and
also
that
this
software
stack
is
running
on
top
of
a
hardware
platform
that
I
know,
and
that
is
the
expected
one.
A
If
I
can
do
both
at
the
station
and
basically
verify
that
what
I'm
running
is
the
is
what
I'm
expecting
to
run,
and
I
can
protect
my
data
from
from
the
host.
Then
I
can.
I
can
really
start
building
this
new
thread
model
where
I
can
safely
remove
the
whole
software
layers
from
my
tcb
from
my
from
my
truss
boundaries.
A
In
order
to
do
this,
there
are
some
hardware
dependencies
protecting
the
data
in
use,
doing
memory,
encryption
and
and
cpu
state
encryption
together
with
at
the
station.
Both
need
hardware
support
you
you,
you
don't
want
to
do
that
in
software,
essentially,
because
if
you
do
that
in
software,
you
again
have
to
trust
the
host,
so
that
needs
hardware
support,
and
there
are
a
few
technologies
coming
from
amd,
ibm
intel
trust
domain
extensions
that
are
providing
those
this
support,
so
those
technologies
in
one
way
or
another.
A
A
A
Okay,
so
now
we've
seen
what
we're
expecting
from
the
emerging
confidential
computing
technologies
to
be
able
to
build
that
new
threat
model.
Let's
see
how
we
could
apply
confidential
computing
to
containers
and
the
goal
here
is
really
to
to
abstract
all
the
dependencies
that
we
just
enumerated
the
hardware
and
software
and
provide
confidential
computing
to
cloud
native
in
a
seamless
form.
We
want
this
to
be
to
be
seamless
for
containers
to
consume.
A
A
So
that
means
you
cannot
protect
your
tenant
data
while,
while
it's
in
use
and
you're
not
going
to
be
able
to
build
that
confidential
computing
thread
model,
the
other
blocker
is
that
sierra
runtime
expect
to
be
able
to
mount
container
images
on
the
host.
So
before
launching
a
container
workload,
they
actually
mount
the
container
image
on
the
host,
and
then
they
let
the
container
the
container
workload
access
it
through
some
namespaces
or
in
in
some
other
cases
through
virtualization
technologies,
but
they
would
access
what's
mounted
on
the
host.
A
If
we
let
the
sierra
runtime
mount
container
images
on
the
host,
we
basically
are
letting
the
host
access
and
tamper
with
our
data,
and
we
cannot
protect
the
tenant's
data
while
it's
at
rest.
So
those
are
the
two
main
blockers
solutions
for
this
solution
for
enabling
confidential
computing
for
containers
are
threefolds.
B
Thanks
samuel,
so,
as
samuel
pointed
out,
you
know
the
solution
space,
one
of
the
things
that
we
think
makes
sense
is
kata
containers,
but
let's
kind
of
get
into
that
in
a
little
bit
more
detail.
So
requirement
is
clear
that
you
need
to
have
a
virtual
machine
in
order
to
be
able
to
leverage
these
extensions,
so
it
needs
to
run
inside
of
a
vm
that
makes
sense
further.
You
know,
based
on
that,
need
to
use
hardware
virtualization
as
the
isolation
layer.
B
So
normally
your
cri
runtime
will
call
into
a
runtime
to
actually
create
the
virtual
machine
and
run
your
pod
inside
of
it.
There
are
a
few
different
sandbox
runtimes
g,
visor,
firecracker
and
kata
containers
are
three
listed
here,
but
you
know
there
are
others
as
well
g
visor.
We
didn't
really
see
as
a
perfect
match.
Just
based
on
you
know
it's
it's
utilizing
the
user
space
kernel.
It's
not!
You
know
it
doesn't
end
up
booting
a
full
virtual
machine,
so
we
didn't
think
that
that
would
be
a
perfect
match
there
firecracker.
B
Similarly,
it's
the
firecracker
runtime
use
utilizing
the
firecracker
vmm.
It
has
some
limitations
device-wise
that
make
it
a
bit
more
challenging
when
using
in
a
kubernetes
environment
and
when
you
have
multi-container
pods
and
everything
else
so
really
we
saw
kata
containers
is
the
more
natural
fit
solution
for
this.
B
So
with
that,
then
the
whole
image
management,
as
well
as
any
real
storage
management.
There
are
kind
of
two
parts
of
it
that
we
want
to
look
at
one
of
them
being
service
offload.
So
when
we
talk
about
service
offload,
we're
really
saying
we
don't
want
to
mount
it
on
the
host
asmr
kind
of
pointed
out
like
we
can.
We
can
do
all
this
work
to
protect
our
data
while
it's
executing,
but
if
we
forget
to
protect
it
at
rest,
we're
kind
of
there's
no
point
in
anything
that
we're
doing
so.
B
We
want
to
avoid
the
cra
runtime
needing
to
mount
or
do
anything
really
with
the
images
on
the
host
so
the
different
ways
we
can
do
it.
One
of
them
is
kind
of
naive,
I
would
say,
and
that
is
to
fully
offload
it
to
the
guest
and
what
I'm
seeing
here
is
that
don't
do
anything
in
in
the
cri
runtime
and
instead
do
the
pull
and
everything
inside
of
the
virtual
machine.
That
makes
it
easy
and
well
easier
in
that
it's
a
single.
You
know
service
operating
inside
the
guest.
B
When
I
said
it
was
naive
before
it's,
you
know
you
can
imagine
a
situation
where
you
have
30
pods
running
on
a
node
and
each
of
them
are
running,
maybe
the
same
image
or
maybe
sharing
most
of
the
layers
of
their
image.
What
you're
going
to
see
is
since
it's
happened
inside
each
guest,
which
means
it
happens
for
every
single
pod.
B
We
do
this
image
management,
there's
no
deduplication,
so
every
single
layer
is
getting
pulled
inside
each
one,
so
it's
kind
of
a
bit
abusive,
maybe
to
the
file
system,
but
even
worse,
probably
for
the
network
as
well
as
you
go
ahead
and
pull
all
these
images
for
every
single
pod
running
on
that
node.
It's
a
good
first
step.
B
I
mean
it
really
does
move
things
away
and
protect
the
data,
but
probably
something
a
long
term
that
you
would
look
at
is
to
do
kind
of
a
mix
where
maybe
you
do
the
pulling
of
the
actual
layers
on
the
host
itself.
So
you
can
have
some
sharing
there,
but
then
present
all
of
these
layers
to
the
guest
and
the
guest
then
would
be
able
to
pick
the
appropriate
ones,
do
the
verification,
decrypt,
etc
inside
the
guest
itself.
B
So
I
would
see
that's
kind
of
the
hybrid
option
I
for
for
the
mixed
and
then
the
next
step
after
that
is
looking
at
you
know
doing
the
encryption
and
verification
itself.
So
great
we're
not
doing
it
on
the
host,
that's
wonderful,
but
now
we
actually
still
need
to
be
able
to
do
the
decryption
and
everything
else.
So
we
need
a
way
to
be
able
to
decrypt
as
well
as
verify.
B
I
say
both
of
those
things,
because
you
can
imagine
a
situation
where
your
image,
you
know
you
have
some
very
confidential
algorithm
that
you're
running
on
top.
But
your
base
image
is
alpine.
You
don't
really
need
to
encrypt
alpine
that
that's
not
a
secret.
You
just
need
to
verify
that
this
is
the
alpine.
You
expect
and
you
can
do
that
through
a
signature
instead,
but
either
way
encrypted
or
verified
everything.
B
That's
inside
the
guest
brought
into
the
guest
needs
to
be
this
and
anytime
that
you
pull
these
things
out
of
the
guest.
You
need
to
have
it
encrypted
as
well.
So
anything
that
is
going
to
be
going
to
rest
and
kind
of
transporting
out.
We
need
to
make
sure
that
happens.
So
that's
another
aspect
of
things
that
need
to
happen.
B
So,
first,
let's
walk
through.
This
is
what
you
know:
a
high
level
flow
of
how
things
operate
today,
if
you're
using
caught
a
clh,
runtime
class,
so
using
kata
containers
with
the
cloud
hypervisor
vmm
starting
at
the
top,
you
know,
cubelet
will
come
in
and
see
like
hey,
there's
a
plot
assigned
to
my
node:
it's
not
there.
We
need
to
start
it
up
go
forward.
First
thing:
it's
going
to
do
is
ask
the
cri
runtime
to
pull
the
image.
B
If
the
image
isn't
already
present,
the
cri
runtime
would
go
ahead
and
and
pull
this
down
and
make
it
available
after
that,
cubelet
would
ask
the
cri
runtime
to
go
ahead
and
create
the
container
in
doing
that.
The
first
step
you
know,
will
be
making
that
image
mounted.
So
that
way
it
can
be
consumed
by
the
container.
B
Then,
after
that,
in
our
case,
it'll
send
a
create
container
request
to
kata
containers
on
the
host
kind
of
containers.
You're
talking
to
is
the
shim
v2,
and
what
that's
going
to
do,
then,
is
start
a
virtual
machine.
So
it's
going
to
be
using
in
this
particular
example:
it'll
be
using
vt
and
kvm.
On
top
of,
that
will
be
the
vmm
cloud
hypervisor
and
that
will
start
the
actual
virtual
machine
once
a
virtual
machine
is
up
you're
running
your
guest
kernel.
The
first
process
that
comes
up
is
the
kata
agent.
B
B
B
Similarly,
people
that's
going
to
do
the
same
stuff,
it's
going
to
say:
hey,
I'm
going
to
run
this
pod,
make
sure
you
pull
the
image
container
d
in
our
naive
case,
we'll
describe
here
we're
going
to
fully
offload
it,
don't
actually
pull
the
image,
just
kind
of
cache,
url,
perhaps,
and
and
just
move
on
and
save
everything's
fine.
Now
keyblade
is
going
to
continue
and
say:
okay,
I'm
ready
to
create
the
sandbox.
I'm
ready
to
create
the
bottom
ready
to
create
a
container.
It's
going
to
issue
create
container
requests.
B
Cri
run
time
doesn't
need
to
do
any
mounting
at
this
point.
Instead,
it's
going
to
just
for
the
information
to
kata
containers
that
same
shim
v2
to
create
the
container
kata
is
going
to
start
up
the
vm.
At
this
point,
it's
going
to
do
the
same
thing.
It's
you
know
going
to
boot
up,
the
kata
agent
is
going
to
come
up,
but
now
it
needs
to
pull
the
image.
So
what
we're
going
to
do
is
we
have
an
attestation
service
we
have.
Essentially,
the
kind
of
agent
will
come
up.
B
It'll
say
this
is
the
image
that
I
need
based
on,
that
it
needs
to
be
able
to
decrypt
it,
and
it's
going
to
need
to
talk
to
a
remote
attestation
agent
or
get
away
to
be
able
to
find
the
keys.
So
it'll
talk
to
that
remote
station
as
an
example
and
it'll
say
this
is
who
I
am
you
know
it
did
a
measured
boot
of
the
host
platform
of
the
kernel
itself
of
the
vmm
of
the
guest
kernel
of
the
kata
agent.
B
B
It's
a
great
new
threat
model
to
be
able
to
provide
that
security
and
privacy
and
everything
else
for
the
end
user.
What
does
it
mean
for
the
developer,
unlike
existing
technologies
today?
Really
it
means
absolutely
nothing.
You
can
get
confidential
computing
without
needing
to
change
your
workload.
You're
just
writing
a
container
the
thing
about.
That,
though,
is
you
really
should
follow
the
same
best
practices
you
always
do,
namely
if
you
have
a
back
door
in
your
base
image
your
your
top
layer
like
this
confidential
is
no
longer
confidential.
B
B
On
top
of
that,
I
I
call
this
a
tenant
user.
This
is
the
person
who's
going
to
do
cue,
cuddle
apply,
you
know,
who's
actually
owning
like
the
the
yaml
who's
who's
running
the
workload
itself.
Maybe
it's
the
same
person
the
developer.
Maybe
it's
maybe
somebody
else
in
doing
that.
What
does
this
really
mean?
B
So
if
you
were
getting
keys
from
a
remote
at
a
station
server,
you
need
to
be
able
to
specify
hey
use
this
url
to
be
able
to
communicate
to
get
the
keys
and
pull
everything
else
down,
so
that
would
have
to
be
custom
per
then
top
of
that
I
would
say.
Maybe
that
was
the
person
doing
the
yaml,
maybe
there's
a
person
who's.
Actually,
you
know
at
the
company
who's
using
the
service
who's
who
set
up
the
infrastructure
for
running
their
workloads.
This
person
would
have
to
one
set
up
an
attestation
service.
B
So
that
way
you
can
go
through
and
take
the
measurement
from
the
cloud
provider
and
be
able
to
see.
Yes,
this
is
the
hardware
and
everything
else.
This
is
what
I
expect
it
to
be
running
in
and
who
would
then
be
able
to
manage
providing
keys
such
that
we
could
decrypt
it
if
everything
looks
good
in
the
running
environment.
B
As
far
as
a
provider
is
concerned,
one
you
have
to
install
a
runtime
that
supports
confidential
computing,
so
I
didn't
put
it
here,
but
that's
that's
kind
of
a
base
start.
If
that's
in
place,
there's
there's
kind
of
a
couple
of
things.
Introspection
doesn't
really
exist
anymore.
So
if
you're
running
like
something
that
goes
through
like
a
falco
or
something
like
that-
and
you
assume
that
you
have
processes
running
the
host
that
you
can
look
at-
you
can't
anymore.
B
So
that's
that's
not
there
and
again,
that's
the
whole
point
of
what
we're
doing,
after
all,
so
a
little
bit
of
a
change
of
how
you
manage
things.
But
two.
There
is
often
like
for
all
the
different
architectures,
the
number
of
keys
that
are
available
for
encrypting
each
trusted
domain.
Each
vm
is
a
finite
resource,
so
you're
going
to
need
to
treat
it
like
a
finite
resource
that
you
can
schedule
against
and
that'll,
be
something
you
know
like
a
device
plug-in
so
that
that's
what
it
means
for
there.
B
Let's
talk
about
gaps,
then
of
where
we
actually
are
today
versus
kind
of
what
we're
working
on
and
what's
coming
in
the
future.
So
on
the
kata
container
side,
there's
a
few
different
parts,
one
is
be
able
to
make
sure
we're
using
a
vmm
that
has
these
apis
to
leverage
the
confidential
computing
hardware
virtualization
and
make
sure
that
in
doing
that,
we
are
creating
configuration
knobs
for
the
user
to
be
able
to
specify
things
like
how
do
we
get
the
keys?
B
How
do
we
do
attestation?
How
do
we
actually
enable
confidential
computing
in
general?
So
adding
these?
On
top
of
that
there's
actual
key
provisioning
again,
depending
on
the
architecture
we're
going
to
be
getting
keys
from
different
ways,
we
could
be
getting
it
from
the
firmware
on
the
host.
We
could
be
getting
it
from
a
remote
server
in
general.
B
We
need
a
way
for
the
kata
agent
to
be
able
to
get
those
keys
so
that
we
can
go
through
and
decrypt
the
images
as
part
of
that
we're
going
to
have
to
be
able
to
do
attestation
we're
going
to
have
to
be
able
to
have
a
set
way
to
be
able
to
have
a
measured
view
up
to
the
point
and
including
the
kata
agent
inside
of
the
guest.
In
order
to
facilitate
you
know
responding
to
a
remote
attestation.
B
That
says
this
is
who
I
am
please
give
me
the
keys
and
then,
on
top
of
that,
the
agent
api
we're
going
to
have
to
lock
down
a
little
bit
more
and
remove
some
of
the
features.
Example,
you
can
keep
control
exact
into
a
container
today
and
poke
around
if
you
can
do
that
in
a
confidential
environment.
Things
are
a
bit
broken,
it's
not
confidential.
You
can
just
access
and
get
in
all
the
different
debug
and
kind
of
ways
to
interact.
B
B
We
can
figure
all
that
out,
but
this
is
this
is
where
it's
a
lot
more
fun
and
interesting,
interacting
with
kind
of
some
of
the
pod
life
cycle
that
we
take
for
granted
and
being
able
to
facilitate
doing
this
image
service
offloading
being
able
to
have
like
a
remote
target
for
who
does
snapshotting
instead
of
inside
the
guest.
So
there's
a
lot
of
opens
there
and
really,
you
know
we're
looking
forward
to
talking
to
folks
on
it.
Similarly,
how
do
we
do
image
layer
encryption?
B
This
is
something
you
know
that
is
beyond
the
scope
of
what
we're
just
looking
at.
This
is
something
already
well
discussed
and
in
progress
from
an
oci
specification
standpoint,
so
overall
stepping
back
some
kind
of
takeaways.
In
summary,
one
conference
computing
requires
vms,
so
keep
that
in
mind,
and
that's
really
again
why
we're
focused
is
kind
of
containers
and
other
vm.
Isolated
workloads
is
a
good
target
for
this.
B
There
are
a
lot
of
different
implementations
from
a
hardware
perspective
on
how
confidential
computing
is
being
carried
out,
but
you
know
our
goal
and
what
we're
working
on
is
to
abstract
it
away.
So
that
way
they
don't
have
to
be
exposed
to
this,
but
still
make
it
clear
to
understand
what
a
level
of
isolation
is
there
for
the
user,
and
you
know
for
the
end
user
who
down
the
road,
just
wants
to
use
this
really.
B
B
Certainly
don't
shouldn't
have
to
change
your
actual
application
itself
and
then
the
last
point
is
that
this
is
very
much
a
work
in
progress,
and
you
know
the
goal
of
kind
of
presenting
here
is
to
really
put
it
out
there
get
people's
to
think
about
it
and
look
for
getting
input
and
discussion
from
folks.
So.