►
Description
Don’t miss out! Join us at our next event: KubeCon + CloudNativeCon Europe 2022 in Valencia, Spain from May 17-20. 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.
Supporting Confidential Workloads with SPIRE - Andrey Brito & Matteus Silva, UFCG
The SPIRE community has already perceived the potential benefits of using confidential computing. Confidential computing can protect sensitive workloads by enforcing stronger attestation but also securing SPIRE components themselves, which in turn helps to make other attestation mechanisms more secure. Nevertheless, providing this support is far from trivial. As it changes SPIRE’s current threat model, there are several challenges to be addressed and tradeoffs to be made clear. In this talk, we share our experience in providing confidential computing support in SPIRE, from the challenges in deriving selectors to the benefits of running other SPIRE components within trusted execution environments, all this while minimizing changes in SPIRE operation and application development workflows.
A
A
So
these
environments
are
called
trust,
execution,
environments
and
they're,
especially
good
for
personal
data,
financial
data,
health
data
that
can
be
very
sensitive
and
even
some
cases
where
you
have
different
stakeholders
which
have
different
data
pieces
and
they
want
to
combine
these
databases
and
train
some
model,
but
not
share
the
data
directly
with
each
other
and
so
sgx
can
and
other
trust
execution
environments
can
help.
You
protect
the
ownership
of
this
data
in
these
cases.
A
And
when
I'm
talking
about
trust
execution
environment,
I'm
mostly
talking
about
intelligence
gx,
which
is
the
one
that
we
have
been
working
with,
because
it's
the
most
common.
So
it's
available
in
several
cloud
providers
in
in
server
off
the
shelf,
servers
and
intel's
checks.
More
specifically,
it
helps
because
it
has
a
reduced
trust
computing
base.
A
So,
typically,
you
have
a
trust
computing
base.
That
includes
not
only
your
workload
but
includes
the
whole
stack,
so
the
operating
system,
the
hypervisor
and
the
hardware,
and
now,
when
you
start
using
intel
stx,
what
you
get
is
that
you
take
the
operating
system
out
of
the
trust
computer
base
and
also
the
hypervisor
and
stays
with
a
much
reduced
tcb
and
in
addition
to
this
reduced
tcp.
A
Of
the
state
that
was
constructed
when
it
was
loading,
and
this
state
includes
code
data
heap
stack
platform,
states
such
as,
if
hyper
threading
was
enabled
or
not.
What
is
the
firmware
version
that
the
processor
was
using
if
it
was
on
debug
mode
or
not,
and
this
is
very
helpful
for
you
to
recognize
when
the
correct
code
is
executing
on
the
correct
platform.
A
Remote
attestation
is
especially
useful
for
our
investigation
here
and
it's
based
on
the
fact
that
challengers
or
remote
applications
can
query
one
application
to
prove
that
is
executing
inside
an
sgx
and
what
is
the
mr
enclave
that
is
associated
with
it.
So
these
applications
that
are
being
tested
have
to
negotiate
with
a
local
enclave.
A
That's
part
of
the
infrastructure,
and
this
local
enclave
will
help
the
application
to
construct
a
quote
that
is
signed
by
a
key
that
is
private
to
that
processor,
and
this
quote
be
presented
back
to
the
challenger,
and
then
the
challenger
can
validate
this
code
with
the
attestation
service
and
once
the
quote
is
valid.
The
challenger
can
look
into
this
report.
This
quote
and
check
if
the
mr
enclave
and
the
platform
characteristics
are
what
it
expected.
A
The
first
one
is
to
secure
the
aspire
component
itself
right,
because
once
you
have
this
sgx
enclaves,
what
you
can
get
is
that
you
can
protect
the
server
by
protecting
its
integrity.
So
if
some
code
in
the
server
gets
changed
by
a
malicious
attacker,
the
server
would
lose
access
to
the
database
could
lose
access
to
the
ca
certs,
and
that
would
prevent
this
attacker
that
got
control
of
the
server
code
to
do
something
malicious.
A
The
other
thing
is
that
you
can
also
protect
the
confidentiality
of
the
secret.
So
even
if
the
code
is
intact,
someone
could
look
into
the
memory
and
still
identities
certificates,
private
keys
by
executing
these
things
within
the
enclaves.
You
don't
have
this
anymore
on
the
agent
side.
What
you
get
is
that
you
can
again
protect
the
integrity
of
the
the
inspire
agent
code
and
you
can
also
protect
the
cached
entries
on
the
agent.
A
They
also
gain
a
lot
when
they
are
combined
with
spire.
First,
you
have
a
more
robust
workload
at
the
station
for
inspire,
so
we
have
already
the
the
ones
related
to
linux,
the
ones
related
to
docker,
kubernetes
and
others.
But
now
you
get
one
that
is
based
on
a
hardware
support
and
that
can
check
if
the
correct
code
is
being
loaded
in
an
up-to-date
processor
and
from
the
confidential
computing
side.
A
You
also
gain
a
lot
when
you
get
the
support
from
spire,
because
now
you
can
have
one
single
way
to
handle
identities
which
which
are
the
spiffy
verifiable
ideas,
but
you
abstract.
What
was
the
actual
attestation
to
that
identity?
For
example,
you
could
have
one
identity
that
reflects
a
highly
trusted
workload
and
this
highly
trusted
status
could
be
gained
because
the
workload
is
executing
inside
an
enclave
even
if
in
a
less
trusted
environment
or
if
the
workload
is
executing
without
the
sgx
support,
but
in
a
trusted
environment
right.
A
So
a
on-premise,
for
example,
that
you
place
that
you
trust
and
this
flexibility
simplifies
the
operation
between
sgx
and
non-stx
workloads,
which
is
a
nice
plus,
because
sgx
by
itself
could
have
a
high,
highly
steep
learning
curve
as
we
advance
it
with
our
development.
We
face
several
challenges
and
I
would
like
to
tell
you
about
feel
of
them
and
the
first
one
is
related
to
the
threat
model.
A
So
it's
not
does
not
make
a
lot
of
sense
because
attacker
that
gains
access
to
the
machine
could
steal
the
identities
of
the
confidential
workload
and
poses
it
the
same
way
as
if
you
protect
a
server
with
sgx,
but
the
database
is
not
protected
by
sjx.
So
what
you
have
things
would
work,
but
an
attacker
could
change
the
entries
in
the
database
forcing
the
server
to
sign
identities
for
malicious
workloads.
A
On
the
workload
at
the
station
side.
There
are
a
few
challenges.
One
is
that
the
regular
workload
decision
plugins
they
rely
on
things
that
come
from
untrusted
sources
of
information
in
this
new
threat
model,
because
now
the
kubernetes
is
the
kernel,
the
docker
engine.
They
are
not
trusted
anymore,
so
you
cannot
use
these
sources
of
information
and
even
the
process
id
that
you
use
to
start
getting
information
about
the
workloads
can
be
changed.
A
So
you
could
get
one
process
id
try
to
talk
to
this
process
id
for
doing
the
attestation,
but
then
an
attacker
reroutes,
your
query
to
the
original
workload.
So
you
end
up
giving
this
vid
to
the
wrong
process
and
that's
something
you
don't
want
the
at
the
station,
as
I,
as
I
mentioned
when
I
was
talking
about
sgx
in
the
remote
attestation
model,
is
also
something
that
needs
to
be
well
considered
because
in
the
spire
model
it
is
done
with
an
out-of-band
communication
and,
as
I
said,
this
out
of
pen
could
be
deviated.
A
But
it's
also
the
case
that
you
don't
want
this
out-of-band
communication
to
give
an
extra
work
to
the
developer,
because
if
the
application
needs
to
be
modified
to
run
with
confidential
computing
and
inspire
at
the
same
time,
you
pose
yet
another
obstacle
to
to
the
adoption
and,
finally,
the
code,
integrity
which
is
given
by
the
mr
enclave.
As
I
just
said,
it's
not
enough
because
we
know
that
configurations
and
and
libraries
and
other
things
that
could
be
on
the
on
the
file
system
could
make
a
difference
on
how
the
application
runs.
A
Operation
is
the
final
challenge,
so
there
are
a
few
things
that
we
need
to
consider
here.
The
first
one
that
I
mentioned
is
that
vm
migrations
are
not
allowed
with
sgx
natively.
So
if
you
have
one
sgx
component
running
a
machine,
a
virtual
machine-
and
this
gets
migrated
to
another
server-
maybe
you
don't
run,
it
will
not
run
anymore.
A
A
And,
finally,
you
have
to
think
about
everything.
So
you
need
to
consider
not
only
the
aspire,
server
and
aspire
agent,
but
other
things
that
will
contribute
to
this
ecosystem,
such
as
the
the
orchestrator
which
should
be
kept,
not
trusted
the
database
that
should
be
trusted
either.
You
run
it
with
sgx
or
you
put
in
a
place
where
you
trust,
but
you
have
to
understand
all
these
points
before
you
have
your
operating
environment.
A
B
B
Second,
leveraging
days
configuration
and
attestation
serves
the
chaos
circumvents.
Some
operation
challenges
for
us
mainly
related
to
sealing
and
configuration,
and
also
we
can
save
some
effort
with
the
development
process
in
this
going
world
discount
workloads
are
defined
by
sessions
and
think
of
think
of
sessions
like
security
policies
and
sessions,
contain
policies
and
staging
conditions
for
the
administration
process,
and
also
some
initiative
of
creation
for
the
workloads.
B
B
B
B
B
We
also
are
collaborating
with
some
folks
at
tu
tresen,
which
are
investigating
ways
to
enable
confidential
clause
to
use
the
workload
api
so
code
that
is
available.
Spf
should
not
need
to
be
changed
to
use
the
confidential
computing
attestation,
plugins
and
and
then
finally,
we
can
consider
some
more
components
of
the
spy
ecosystem,
just
like
upstream
authority
plugins,
the
usage
of
federation
aspire
database
and
so
on.