►
Description
Don’t miss out! Join us at our upcoming hybrid event: KubeCon + CloudNativeCon North America 2022 from October 24-28 in Detroit (and online!). 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.
Confidential Containers Explained - James Magowan, IBM & Samuel Ortiz, Apple
Confidential Containers (https://github.com/confidential-containers) enable cloud native confidential computing (https://confidentialcomputing.io/faq/) leveraging a variety of hardware platforms and technologies, standardising the confidential computing at the container level, helping users to deploy confidential workloads using already familiar workflows and tools; and in this Panel we're bringing together contributors from different hardware vendors, different projects (in different layers of the stack), and different companies to discuss and answer questions about this new complex technology. Topics for discussion will include: * How do we realise the benefits of cloud native confidential computing? * What impact is there to the Cloud Native User Experience? * What new considerations/concepts does confidential containers introduce? Note that this panel is a follow-up on what has been developed since https://www.youtube.com/watch?v=zTn9Xt1k1OA was presented.
A
A
And
yeah
we're
going
to
talk
about
conversational
computing
cloud
native
containers
kubernetes
and
how
we
kind
of
all
mix
together
so
before
going
there,
this
was
to
be
this
was
supposed
to
be
a
panel,
but
it's
not
going
to
be
a
panel.
It
was
supposed
to
be
a
panel
with
both
of
us
plus
three
other
people,
archana
from
intel
and
jiang
from
alibaba,
and
predicts
that
from
red
hat
but
yeah.
It
was
basically
five
speakers.
Five
time
zones
we
were
supposed
to
be
to
do
live
pre-recording
yeah.
A
What
could
possibly
go
wrong
right
and
try
to
find
the
right
time
for
pre-recording
something
with
five
different
time
zones?
We
couldn't
make
it
so
we
asked
for
change
and
we're
gonna
give
this
presentation
here,
but
it's
gonna
be
a
kind
of
an
hybrid
way
of
presenting
we're
gonna,
basically
ask
some
questions
and
try
to
answer
those
questions.
So
what
you
will
learn
today
are
answers
to
those
questions.
A
B
And
then
I
guess
the
last
question
is
who's
aware
of
what
a
trusted
execution
environment
is
okay.
Well,
the
good
thing
is:
we've
got
a
fair
mix
and,
as
I
went
down
that
we
had
more
people
aware
of
what
we
were
talking
about,
but
when
we
go
through
the
questions
and
answer
them
we're
hoping
to
satisfy
everyone's
prior
knowledge
so
to
facilitate
that
normally
in
a
panel
we'd
have
five
people
slightly
differing
views.
B
So
as
we
go
through
it,
samuel's
gonna
lead
you
in
and
draw
you
in
technically
and
then
I'll
bring
you
back
gently
to
a
less
technical
view.
As
a
recap,
as
we
go
along
so
hopefully
we
will
cater
at
a
level
that
kind
of
suits
everyone's
prior
knowledge,
but
obviously
we'll
take
questions
towards
the
end
and
we'll
be
here
afterwards
and
well
all
week.
So
thanks.
A
A
So
the
the
computational
continuous
project
is
a
set
of
open
source
components
and
the
goal
for
this
is
to-
and
there
are
some
keywords
there-
that
I
want
you
to
highlight
the
goal.
The
real
the
goal
of
the
project
is
to
seamlessly
run
kubernetes
workloads
in
their
own
confidential
computing
enclaves,
also
known
as
trusted
execution
environments.
A
I
also
want
to
highlight
the
fact
that
this
is
an
open
source
community,
obviously
with
a
contribution
participation
from
already
a
bunch
of
key
stakeholders,
cloud
providers
like
alibaba
and
ibm
silicon
vendors,
so
the
people
who
are
actually
implementing
on
in
hardware
the
trusted
execution
environment,
the
computational
computing
hardware,
like
amd
ibm
intel
arm,
is
also
starting
to
participate.
Those
are
participating
to
to
this
project
and
open
source.
Vendors
like
red
hat,
also
are
contributing.
A
A
The
first
one
is
that
you
have
a
pod
and
your
pod
has
a
dedicated
confidential
virtual
machine
and
a
com.
Why
a
computational
virtual
machine,
because
in
practice
computational
computing
is
implemented
as
a
hardware,
virtualization
extension.
So
when
you
talk
about
confidential
computing,
when
you're
talking
about
suv
or
tdx
or
se,
you
end
up
actually
running
something
inside
a
virtual
machine
and
what
we're
doing
with
confidential
containers
is
taking
that
something
which
is
your
kubernetes
pod
and
run
it
inside
a
confidential
computing
virtual
machine.
A
So
each
and
every
one
of
your
part
with
confidential
containers
will
run
inside
its
own
tdx
scv,
sgx
enclave
and
that's
the
very
important
point
there's
another
one
which
is
the
enclave
agent.
That's
a
controlling
agent!
That's
running
inside
a
virtual
machine.
That
kind
of
sets
the
computation
computing
environment-
and
this
is
a
very
high
level
diagram,
we'll
go
into
more
details.
As
we
answer
more
questions.
A
So
how
does
that
relate
to
computational
computing?
How
does
computation
containers
use
the
confidential
computing
hardware
and
implementation
and
features
again
with
confidential
containers?
Each
kubernetes
spot
gets
its
own
enclave,
getting
sold
confidential
computing
enclave.
What
does
that
mean?
First
of
all,
that
means
that
your
kubernetes
pod
is
going
to
have
its
memory
encrypted
through
hardware,
but
not
only
memory,
so
it
will
also
also
have
its
cpu
states
and
hardware
state
in
general
encrypted.
A
It's
it's
it's
that
so
we're
using
the
the
memory
encryption
and
the
hardware
encryption
features
of
continuous
computing,
but
we're
also
using
with
confidential
containers.
Another
very
important
feature
of
confidential
computing,
which
is
at
the
station
running
with
memory.
Enable
is
one
thing
with
memory:
encryption
enable
is
one
thing,
but
with
memory
encryption
enabled
you
enable
you
basically
are
saying
that
your
host
is
not
able
to
see
what
your
community
spot
is
doing,
but
you
are
no
guarantee
about
what
you,
what
your
kubernetes
part
is
actually
running.
A
The
software
stack
that
is
running
so
it
can
be.
It
can
be
controlled
by
the
by
the
by
the
the
csp
by
the
infrastructure
owner,
and
we
want
to
prevent
that
from
happening.
We
want
to
control,
what's
actually
creating
this
data,
that
you're
going
to
be
encrypting
with
hardware
memory
encryption
and
to
do
that
we
use
attestation
the
attestation
features
of
computational
computing.
Basically,
with
confidential
containers,
you
have
an
enclave
stack,
so
there's
a
stack,
that's
running
inside
the
virtual
machine.
A
That's
going
to
run
your
community
spots
that
is
trusted
and
verified
through
confidential
computing
at
the
station,
and
typically
this
is
basically
remote
at
the
station.
So
you
have
an
enclave
stack.
That's
running
inside
your
virtual
machine.
That's
going
to
be
dedicated
to
your
pod
and
this
enclave
stack
is
trusted.
It's
something
that
you
can
verify
from
top
to
bottom.
That
is
running
exactly
what
you
need
and
exactly
what
you
want
as
a
guest
owner
again.
A
An
illustration
of
this:
this
is
the
high
level
view
if
we
go
into
a
little
more
details.
First
of
all,
we
have
this
enclave
stack
that
I
that
I
mentioned,
which
covers
everything.
That's
your
that
your
virtual
machine,
your
confidential
virtual
machine,
is
going
to
run
from
firmware
to
any
tardy,
so
that
includes
the
firmware,
the
guest
kernel
and
the
guesting
authority,
plus
an
agent,
the
enclave
engine.
That's
typically
part
of
the
of
the
nhrd
with
confidential
computing.
A
We
are
encrypting
all
this.
So
all
the
memory,
all
the
cpu
state
that
this
virtual
machine
is
going
to
be
using
leverages,
computational
computing,
encryption
capabilities
to
encrypt
all
this
and
we're
also
measuring
the
enclave
stack.
So
all
the
components
that
are
part
of
the
enclave
stack,
the
firmware
the
kernel,
the
init
rd,
the
current
command
line,
all
the
parameters
that
you
want
to
add
to
your
measurement.
You
can
measure
that
and
measuring
means
that
you
can
verify
it.
A
So
there's
a
relying
party,
that's
outside
of
your
node
that
can
be
used
that
can
be
controlled
by
you
as
a
guest
owner
to
actually
verify
that
this
enclave
stack
is
exactly
what
you're
expecting
so
before
starting
the
pod.
Before
running
anything
on
your
on
your
confidential
computing,
vm
you're
going
to
be
able
to
verify
that
what's
going
to
be
running,
this
kubernetes
part
is
exactly
what
you
expect
has
not
been
tempered
by
by
the
the
infrastructure
owner.
A
It's
not
going
to
be
able
to
mess,
or
even
look
at
the
memory
that
your
kubernetes
workload
is
generating.
But
that's
not
enough.
If
you
only
have
this,
you
have
no
guarantee,
you
don't
know,
what's
generating
this
data,
so
you
need
to
make
sure
that
what's
generating
this
data
is
what
you
defined,
what
you
built
and
what
you
want
and
to
do
that
we're
using
memory
measurement
and
and
at
the
station.
So
the
guest
runs
again:
the
enclave
stack.
The
enclave
stack
is
completely
measured,
verified
by
you
as
a
guest
owner
through
remote
association.
A
A
The
first
thing
you
do
is
verify
that
your
enclave
stacks,
the
stuff
that's
running
inside
the
confidential
vm,
that
your
community
spot
is
running
on
is
verified.
Once
you
have
done
this,
your
enclave
stack
through
the
enclave
agent
is
pulling
the
container
image
and
keeping
the
container
image
inside
the
enclave.
So
the
container
image.
What's
what
really
matters
to
you?
What
your
workload
definition
is
kept
inside
this
virtual
machine
image.
It
keeps
inside
this
this
virtual
machine
memory
and
is
protected.
A
What
we
do
once
we've
verified
once
we
know
that
the
enclave
stack
is
trusted.
The
relying
party
is
going
to
inject
secrets
into
the
confidential
virtual
machine.
Typically,
the
secret
is
an
encryption
key.
It's
an
encryption
key
that
you're
going
to
use
to
pull
a
container
image
that
is
encrypted
and
decrypt
it
inside
your
virtual
machine.
So
you
pull
an
encrypted
image
from
any
registry
public
private.
Whatever
it's
encrypted,
you
keep
it.
A
You
keep
it
inside
the
virtual
machine
and
you
decrypt
it
with
what's
been
provisioned
to
you
by
your
relying
party
after
verifying
that
you're
enclave
stack
the
component
that
the
your
virtual
machine
is
running
is
verified
and
you
trust
it.
So
none
of
this
is
visible
by
the
host.
None
of
this
is
visible
by
the
csp
or
by
the
infrastructure
owner.
B
So,
at
this
point,
having
drawn
you
in
technically
samuel's,
explained
a
lot
and
gone
into
the
detail,
I'm
gonna
wind
back
a
bit
catering,
perhaps
more
for
those
who
didn't
answer.
Yes
to
any
of
the
questions
I
asked
at
the
start,
so
to
start
with,
if
this
technology
is
out
there,
we
have
trusted
execution
environments.
B
B
That's
outside
our
trust,
so
that
boundary
that
we
want
to
put
leaves
the
workload
inside,
but
the
orchestration
and
management
of
on
the
outside
is
such
a
way
that,
however,
it's
managed
can't
change
the
workload
that
we
trust
can't
get
access
to
the
data,
the
algorithms
or
whatever
else
that
we've
got
in
our
workload
and
that's
the
kind
of
separation
that
we're
aiming
for
here.
So
what
does
that
mean?
B
Well,
it
means
that
if
we
take
a
trusted
execution
environment
today,
it's
essentially
a
secure
environment
in
which
you
can
put
your
workload,
whether
it
be
containers
or
whatever,
and
if
all
you're
doing
is
considering
a
pure
vm
approach,
a
virtual
server
approach.
Then
you
define
through
your
workload
the
apis.
B
You
define
what
crosses
that
boundary
so
you're
in
complete
control
of
what
gets
into
that
trusted
execution
environment
just
because
you
control
the
workload
of
the
application,
but
as
soon
as
you
start
to
put
that
into
an
orchestrated
world
into
a
cloud
native
word,
there
are
other
things
that
need
to
cross
that
boundary
to
do
with
the
orchestration
actions
to
do
with
starting
the
containers
or
monitoring.
What's
happened
and
if
you
go
to
an
extreme,
there
are
capabilities
that
would
cross
that
boundary.
B
That,
for
example,
would
allow
you
to
execute
an
arbitrary
shell
command
inside
a
container,
for
example,
which
doesn't
really
fit
with
what
we're,
after
here
in
terms
of
confidential
computing.
Now
that
would
be
a
complete
nightmare
if
you're
trying
to
suggest
that
your
workload
is
secure.
If
somebody
could
do
something
that
extreme
as
it
were,
so
I
mean
what
we're
after
here
is.
You
could
use
a
trusted
execution
environment
to
wrap
different
things
and
we
could
use
it
to
wrap
a
node,
for
example,
but
essentially
the
management
of
the
cluster
lives
inside
that.
B
So
that's
why
we
settled
on
that
bindery
around
the
pod
as
a
way
of
kind
of
neatly
suggesting
that
those
who
are
defining
the
workload
can
have
more
control
of
from
inside
the
pod,
leaving
the
management
of
the
cluster
to
happen
as
as
normal-
and
I
guess
this
is
the
next
key
point
where
we're
putting
some
control
into
the
pod.
So
samuel
mentioned
about
the
pulling
of
containers.
B
Essentially,
what
we're
driving
here
is
that
I
want
to
define
a
workload
that
could
be
deployed
in
a
cluster,
and
I
want
to
know
that
it's
deployed,
as
I
expect
it,
to
be
deployed
it's
deployed
into
a
trusted
execution
environment.
It's
using
the
images
that
I
want
that
the
orchestration
actions
that
can
be
carried
on
out
on
it
are
in
my
control,
and
so
in
that
respect,
I
need
to
be
able
to
define
that
such
that
the
pod
has
control
over
that,
because
I
can
define
the
workload.
That's
what
happens
in
the
pod.
B
I
can
control
the
containers
of
traveler
if
I
encrypt
them
or
sign
them,
then
that's
something
that
can
be
provided
as
a
result
of
attestation
so
that
when
it
starts,
when
my
workload
starts,
whatever
combination
of
pods
start,
I
know
the
only
way
they
could
have
started
is,
if
they've
received
the
secrets
that
I've
provided
and
as
a
result
of
a
testing
that
the
basic
confidential
vm
that
I'm
expecting
to
happen
is
there
and
outside
that.
I
don't
care
what
the
workload
sorry,
what
the
administrator
has
done.
B
Yes,
they
are
in
control
of
denial
of
service
and
things
like
that.
But
that's
what
their
least
privilege
is.
That's
what
they're
supposed
to
be
doing?
What
I
don't
want
them
to
be
doing
is
changing
my
workload,
starting
it
outside
a
trusted
execution
environment,
getting
access
to
the
data
that
I
want
to
protect
or
the
algorithms
I
want
to
protect,
and
the
last
thing
that
brings
this
all
together
is
that
we
don't
want
to.
As
samuel
said,
we
don't
want
to
pursue
a
completely
different
paradigm
for
doing
this.
That's
not
what
this
is
about.
B
We
want
to
fit
with
the
experience
and
expectations
that
are
out
there.
The
last
thing
we
want
to
do
is
to
change
the
whole
way.
You
would
manage
your
cluster
and
higher
that's
thought
about.
We
don't
want
to
change
the
whole
way
that
a
workload
is
is
defined
so
there's
an
element
of
sometimes
new
ideas
come
with
some
friction
that
changes
what's
there
before.
We
are
aiming
to
reduce
that
friction,
so
essentially
nothing
changes
for
the
majority
of
personas
and
actors
and
what
they
do.
Nothing
changes.
You
still
manage
a
cluster.
A
Which
basically
means
yes,
if
you
have
a
workload
definition,
a
pod
spec
with
configuration
containers,
you're
going
to
keep
the
same
thing,
but
inside
your
workload
inside
your
virtual
machine
you're
free
to
define
and
run
it
as
you
wish
and
define
those
boundaries,
but
from
a
workflow
perspective,
yeah.
Nothing
changes
pretty
much
so
next
question
now
that
we
talked
about
this,
how
can
you
use
and
deploy
computational
containers
quickly,
because
I
think
yeah
we're
on
time
as
part
of
competition
containers.
A
We
have
many
components,
but
one
interesting
one,
which
is
it's
kind
of
the
integration
point
of
the
the
whole
project
is
the
kubernetes
operator.
So
we
have
an
operator
for
confidential
containers
that
allows
you
to
deploy
confidential
containers
as
easily
as
possible
inside
your
inside
your
kubernetes
deployment.
A
Basically,
that
will
allow
you
to
deploy
the
the
right
runtime
to
build
the
right
enclave
stack
that
that
you
want
to
configure
it
properly
and
deploy
that
and
run
it
with
the
with
the
with
the
specific
runtime
that
you
defined
to
through
the
operator
that
run
time.
I
haven't
mentioned
it,
but
for
most
of
it
is
we're
using
the
the
catalog
containers
runtime,
which
is
a
natural
fit
for
running
kubernetes
work,
kubernetes
parts
inside
virtual
machines,
so
we're
taking
this
runtime
we're
adding
some
features
to
it.
B
B
There
we
go
so
why
do
we
care
so
we're
not
here
to
redefine
what
the
use
cases
are
for
confidential
computing,
they're
they're
out
there
they're
well
trodden
path.
If
you
care
about
your
data,
if
you
care
about
algorithms,
for
example,
in
an
ai,
then
you're
interested
in
protecting
them,
essentially,
if
you're
in
industries
that
have
concerns
about
regulatory
requirements
or
compliance
or
things
like
that
or
worst
case
scenario.
B
If
you,
your
very
existence
as
a
company
depends
upon
protecting
the
data
that
you're
privileged
enough
to
be
using
then
confidential.
Computing
is
a
concern
to
you,
but
what
we're
trying
to
do
here
is
set
it
in
the
context
of
what
does
it
mean
for
cloud
native?
What
does
it
mean
to
hire?
We
would
administrate
our
clusters,
and
this
comes
down
to
technical
assurance
versus
operational
insurance,
and
what
I
mean
by
that
we
can
configure
a
cluster
and
we
can
configure
web
hooks,
sidecars,
etc.
B
That
would
check
what's
happening,
but
fundamentally
who's
in
control
of
that
access
code,
who's
control
of
those
web
books.
Is
it
the
person
that
we
want
to
be
in
control
of
that?
Because
what
we're
talking
about
here
is
trying
to
have
that
control,
or
at
least
certain
portions
of
that
control
reside
with
the
person
defining
the
workload
not
with
the
person
administrating,
the
cluster.
So
what
I
mean
by
technical
assurance
here,
is
it
doesn't
matter
how
the
cluster
is
configured?
B
It's
not
possible
to
do
certain
things,
because
in
defining
the
workload
you
have
made
those
things
not
possible.
So
essentially,
if
the
cluster
or
environment,
in
which
you're
running
your
workload,
goes
against
the
things
that
you've
said
in
the
workload
itself
are
required.
Well,
then
the
attestation
will
fail.
B
You
won't
get
the
secrets,
the
workload
won't
run,
and
so
that's
what
we
mean
by
technical
assurance
versus
operational
insurance
and
that's
that
separation
of
personas,
where
we're
putting
more
of
that
control
into
the
hands
of
where
we
define
the
workload,
because
after
all,
why
should
the
person
administer
it
in
the
cluster?
Have
privileges
that
allow
them
to
change
containers
that
are
running
that
allow
them
going
back
to
the
the
obvious
example.
Allow
them
to
arbitrarily
execute
a
shell
command
in
a
container.
A
So
yeah
use
cases,
as
jim
said,
I
mean
it's,
it's
not
really
different
from
regular
computational
computing
use
cases,
basically
you're
taking
the
infrastructure
owner
out
of
the
trust
boundary.
That
gives
you
a
lot
of
potential
use
cases.
One
one
interesting
one
is
that
you
basically
can
run
your
sensitive
workloads
anywhere
where
competition
computing
is
enabled.
A
A
Maybe
the
infrastructure
owner
is
someone
that
you
don't
want
to
have
a
look
at
your
workload.
Even
internally
with
competition
computing
competition
configuration
container
sorry,
you
can
run
that
safely,
at
least
so,
basically
moving
from
private
to
public.
If
your
public
cloud
is
giving
you
access
to
confidential
computing,
that
becomes
possible,
whatever
your
workload
is.
B
B
That
would
be
madness
to
suggest
that
I
think
what
we're
talking
about
here
is
a
progression
that
it's
more
secure
than
what
was
there
before,
but
it's
a
journey
that
we're
on
with
confidential
containers
and
what
we
really
want
to
do
is
to
start
to
connect
with
other
groups
here
to
understand
how
existing
projects
and
existing
things
in
a
cloud
native
world
could
either
take
advantage
of
confidential
containers
or
would
work
with
confidential
containers
to
progress
that
story
to
make
it
more
secure
than
before.
To
start
that
journey
to
confidential
computing.
A
A
So
we
are
working
on
defining
a
protocol
that
is
simple
enough
for
everyone
to
comply
with
for
attestation
service
and
key
brokering
service
in
the
competition
containers
context.
So
we're
expanding
on
this.
One
thing
that
we
are
also
working
on
is
adding
secure
storage.
How
do
you
inject
data
volume
inside
a
confidential
vm
and
we're
defining
this?
We
have
a
good
architecture,
design
and
a
initial
implementation
for
this,
and
when
we're
going
to
put
all
this.
A
B
D
E
A
Is
a
very
common
question?
Basically,
how
do
you
observe
a
confidential
computing
virtual
machine?
And
I
think
we've
been
thinking
about
this
there's?
No
there's
no
good
answer
to
this.
There's
no
magic!
You
know
magic
answer
for
this,
but
basically
one
way
we're
exploring
is
is
is
about
saying
if
you
want
to
observe
something
into
the
competition
competing
vm
you're
going
to
have
to
run
side
cars,
but
those
side,
cars
needs
to
be
verified
by
you
as
a
guest
owner.
A
So
it's
okay
to
run
side
cars
alongside
your
kubernetes
competition,
continuous
pod,
as
long
as
you
as
a
guest
owner
can
say.
Yes,
this
is
the
sidecar
I'm
expecting
and
I'm
allowing
this
sidecar
to
observe,
what's
happening
inside
my
confidential
computing
vm.
So
that's
that's
one
way
to
explore
it
sidecar
and
basically
allowing
the
the
infrastructure
owner
to
inject
anything
in
the
pod
is
kind
of
antinomic
to
the
the
whole
confidential
containers
concept.
So
there
will
be
restrictions.
A
B
Yeah,
I
mean
it
I'll,
take
the
backwards
step
again.
Some
elements
of
observability
have
to
be
in
the
control
of
the
person
defining
the
workload
fundamentally
and
that's
basically,
whether
that
be
in
control
of
verifying
which
containers
are
added
for
that
purpose
or
whether
it
be
in
control
of
some
other
means
of
controlling
what
can
be
logged
or
monitored.
Within
that
context,
some
element
of
that
control
has
to
reside
with
the
workload
provider.
F
Hello,
my
name
is
nick
vidal.
We
actually
have
an
open
source
project
called
anarchs
and
we
we
combine
web
assembly
with
confidential
computing
and
we
are
we're
part
of
the
confidential
computing
consortium,
and
I
wanted
to
ask:
are
you,
of
course
you
are
on
open
source
project?
I
saw
your
your
github
page,
but
are
you
also
part
of
the
cncf
or
the
confidential
computing
consortium?
A
So
I
guess
the
answer
is
here:
we
are
cncf
sandbox
project
and
if
you
look
at
the
bottom
of
the
slides,
those
are
the
companies
that
are
currently
contributing
to
the
project.
So
we
we're
fully
aware
of
anarch's
existence,
and
I
think
this
is
what
james
was
highlighting.
We
probably
need
to
talk
and
understand
how
those
kind
of
project
can
live
together
and
if
there's
you
know,
maybe
there's
some
way
to
converge,
maybe
there's
no
way
to
converge
and
two
different
projects
different
provide
different
values.
A
E
Question
hello:
I
was
interested
in
finding
out
how
do
you
if
I'm
running
this
framework
on
a
public
cloud,
you
said
you
have
an
operator.
So
how
do
you
attach
the
operator?
How
do
I
know
if
I
am
deploying
the
operator
while
deploying
the
provider
doesn't
mess
in
with
it,
and
then
everything
is
kind
of
I.
A
I
think
the
answer
is
that
you
you
can
you
can't
really
do
this,
so
if
the,
if
the
csp
really
wants
to
mess
with
this
it
can,
but
then
you
won't
be
able
to
to
a
test
and
verify
the
workload
that
you
run.
The
only
thing
that
you
care
is
that
you
can,
when
you
start
a
workload
when
you
ask
for
your
competition
computing,
computation
containers,
ngnx
workload
to
be
running,
you
want
to
make
sure
that
this
is
the
right
container
image.
A
B
I
mean
it
comes
back
to
to
the
whole
attestation
flow.
You
have
to
accept
that
that
rule,
that's
administering
your
cluster
can
change
what's
there,
but
at
the
end
of
the
day,
if
that
workload
starts
outside
of
that
confidential
vm,
that's
measured,
it
won't
receive
the
secrets
required
for
your
workload
to
actually
start
and
those
could
be
things
like
simple
keys
to
decrypt
containers.
It
might
be
certificates
for
tls.
E
A
They
could
be
compromised,
yes,
but
if
you
it
doesn't,
even
if
they're
compromised
but
you're
still
running,
and
if
you,
if
they
can
bear
so,
let's
say
the
operator
changes
the
the
gas
kernel.
Okay,
you
change
the
gas
kernel.
This
is
going
to
be
measured,
this
is
going
to
be
verified
and
the
attestation
is
going
to
fail.
So
if
the,
if
the
csp
change
the
guest
kernel
that
your
confidential
container
is
going
to
run,
you're
never
going
to
be
able
to
run
your
container
image
and.
B
Maybe
there's
an
element
here
to
push
on.
We
would
not
imagine
that
the
operator
is
also
setting
up
the
attestation
flow
as
it
were
that
that
measurement
that's
recorded
in
the
attestation
service
needs
to
be
done
outside
of
the
operator.
So
the
control
of
that
is
not
within
the
control
of
the
kubernetes
administrator,
because
if
they
could
control
that
then
you're
quite
right,
they
could
change
anything
they
want,
and
then
you
wouldn't
know,
but.
A
C
A
The
the
workload,
so
you
have
two
parts
on
the
workload.
The
first
one
is
the
what
we
call
the
enclave
stack,
which
is
basically
what
boots
the
confidential
virtual
machine
that
actually
talks
to
the
hardware
and
gets
the
hardware
to
generate
the
attestation
report.
So
the
hardware
has
measured
the
firmware,
the
kernel
and
the
the
component
that
actually
even
that
actually
asked
for
the
attestation
report.