►
Description
Attestation and identity provisioning to Intel SGX workloads - Andrey Brito
Using workload attestation mechanisms to provision identity to workloads adds a huge value to this identity, especially in multi-cloud environments. Strong identities simplify policy management and help integration between services. However, attesting workloads based on properties collected from the Linux Kernel or the orchestrator is just the beginning. With confidential computing mechanisms reaching public cloud providers, there is an opportunity to raise the bar on the supported threat model and the strength of the application identities using technologies such as Intel SGX.
In this talk, I will explain how having an SGX Attestor could lead to identities that reflect not only where code is running, but also reflect the code of application that was actually loaded and the configuration of the filesystem that supports it. Next, I will discuss the benefits of such an attestor, which include enabling the seamless integration between sensitive workloads in untrusted environments with workloads on trusted environments with almost no additional burden on the developer.
Don’t miss out! Join us at our upcoming event: KubeCon + CloudNativeCon Europe 2021 Virtual from May 4–7, 2021. Learn more at kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.
A
A
So
in
the
attestation
process
it
includes
not
only
the
measurement
of
the
code
that
was
loaded
and
some
other
things
that
were
used
to
create
this
enclave,
so
to
say,
but
also
includes
information
from
the
platform,
for
example,
the
the
firmware
version
that
was
used
if
hyper
threading
was
enabled
if
it
is
a
debug
mode
or
production
mode
enclave,
and
once
you
have
this
measurement
of
the
application,
and
you
have
the
information
on
on
the
platform
security.
This
is
packed
in
something
that
we
call
the
quote.
A
So
with
this
very
basic
concepts,
we
should
think
now
about
how
do
you
develop
code
for
intel
sgx,
and
the
first
approach
is
not
the
most
exciting.
One
is
the
one
that
you
you
need
to
use
when
you
want
to
the
most
flexibility,
you
want
to
minimize
your
trust
computing
base.
You
want
to
minimize
the
usage
of
the
protected
memory,
and
that
means
that
you
will
probably
be
writing
from
scratch
using
c
or
c
plus.
Your
trusted
code
cannot
do
system
calls
and
you
have
to
implement
yourself
at
the
station
and
mitigations
for
vulnerability.
A
Resecute
build
your
container
again
and
everything
works
in
the
less
lucky
path.
What
happens
is
that
you
may
need
to
recompile
your
application,
or
maybe
you
need
to
use
alternative
packages
or
libraries,
for
example,
from
a
different
linux
distribution,
but
it's
easier
much
easier.
You
don't
have
to
rewrite
your
code
and
when
you
do
that,
although
you
need
a
bit
more
protected
memory
and
you
use
a
bit
more
of
your
protected
memory
and
your
trusted
computer
base,
you
do
inherit
a
few
things
that
can
be
done
in
the
runtime.
A
So,
for
example,
if
you
implement
security
mitigations
on
the
runtime,
this
can
be
inherited
by
the
applications
running
on
top
of
those
runtime
right
and
regarding
the
the
protected
memory,
according
to
some
recent
announcements
from
from
intel,
that
should
not
be
an
issue
early
next
year,
okay
and
then
so
just
to
give
you
an
example
about
how
you
can
import
your
application.
This
is
an
example
of
a
happy
path,
so
you
just
have
your
docker
file
with
a
python
based
image,
and
then
you
replace
your
base
image
and
then
everything
should
work.
A
So
in
this
case,
what
happens
that
the
the
new
image
has
a
version
of
python
that
was
recompiled
with
the
the
runtime,
and
in
this
case
we
are
using
the
scone
runtime
a
set
of
tools
that
enable
the
compilation
and
the
execution
of
of
sjx
workloads
in
another
way.
To
do
that?
The
the
second
example,
then,
you
could
have
microservice
written
in
another
language
like
c
or
even
fortran,
and
and
then
you
can
recompile
it
using
the
the
two
set.
In
this
case,
I
used
another
base
image.
A
Then
the
first
thing
to
talk
about
is
that
we
can
have
a
more
aggressive
threat
model,
so
a
threat
model
where
the
the
attacker
can
have
super
user
privileges,
and
this
can
happen
for
several
reasons.
The
the
operator
may
be
forced
to
give
this
access
to
someone.
The
attacker
could
have
stolen
the
credentials
from
the
infrastructure
operators
or
something
maybe
compromised
in
the
infrastructure.
A
A
But
one
thing
that
I
would
like
to
take
out
of
the
discussion
now
is
that,
let's
assume
that
the
sgx
itself
is
free
of
bugs,
so
the
processor
is
free
of
bugs
the
runtime
and
the
libraries,
and
also
that
the
the
workload
doesn't
have
some
silly
api
that
exposes
everything
without
authentication
and
lastly,
I'm
also
assuming
that
the
expiry
server
will
be
trusted.
So
there
will
be
no
one
issuing
ids
for
other
workloads
that
are
not
the
database
x
ones.
A
So,
with
this
threat
model
in
mind,
there
is
a
clear
motivation
to
do
this
integration,
so
the
very
basic
one
is:
if
you
have
a
set
of
services
that
you
trust,
then
maybe
now
you
can
be
more
open
to
services
that
are
running
on
a
remote
infrastructure
that
you
do
not
trust
if
they
are
running
inside
sgx
and
then
you
can,
you
do
not
need
to
make
your
application
more
comp
complex.
You
just
give
them
ideas
that
reflect
this
status.
A
The
other
thing
is
the
exactly
the
opposite.
Maybe
you
have
some
sjx
workloads
and
you
want
to
make
them
talk
to
non-stx
workloads,
but
you
want
at
least
some
evidence
that
they
are
on
a
reasonable
platform,
so,
for
example,
that
they
are
on
the
correct
cloud
provider
and
the
correct
security
group,
as
you
do
normally
with
spiffy
identities,
and
the
last
one
is
something
that
I
consider
very
interesting
and
promising
is
that
you
could
actually
put
small
ghost
tuners
inside
your
application.
A
So,
for
example,
because
you
have
to
anyway,
when
you're
executing
executing
your
application
inside
sgx,
you
have
to
intercept
all
the
communications,
and
this
is
done
transparently
by
the
runtime.
Then
it's
not
difficult
to
wrap
this
communication
inside
tls
connections
and
then
this
tls
connection,
something
that
it's
been
called
network
shooting
could
be
actually
using
spiffy
ids
on
the
outgoing
connections
and
checking
for
spf
ids
on
the
incoming
connection.
So
in
a
way
you
have
a
transparent
adoption
of
spiffy
identities.
A
A
We
have
the
workload
registration
process
that
includes
the
a
name,
a
name
of
a
session,
and
the
session
is
what
is
how
we
call
the
configuration
of
an
application
in
the
configuration
of
the
application.
It
describes
not
only
the
executable,
but
also
the
state
of
the
file
system
that
supports
that
execution.
A
So
finally,
we
have
the
workload
which
will
run
in
a
in
a
node
that
doesn't
have
an
agent
and
the
the
workload
wakes
up
and
gets
its
svid,
its
identity
from
the
sjx
secret
store,
and
then
it
can
use
this
speed
for
those
things
that
it
always
do.
And
finally,
we
have
this
as
a
attestation
helper,
which
is
the
the
role
of
that
boating
enclave.
That
is
necessary
for
the
sgx
conversation
to
provide
evidence
of
the
the
code
in
the
platform,
so
here's
a
flow
of
the
the
process.
A
A
Next
in
step,
two,
the
the
operator
or
somewhere,
someone
else
will
register
the
workload
associating
the
hash
of
that
first
configuration
to
a
svid
to
a
spf
id
right.
So
once
the
association
is
created,
then
the
aspire
server
will
start
meeting
this
vids
based
on
that
that
id
and
this
speed
will
be
propagated
through
the
helper
to
the
secret
store.
A
Then,
eventually,
the
operator
will
deploy
the
workload
and
when
the
workload
is
deployed,
the
as
it
starts
it
will
transparently
talk
to
the
attestation
service
into
the
secret
store
and
then
get
access
to
its
speed.
So
in
our
case
we're
using
a
the
certificate.
So
the
x
509-
and
one
thing
that
is
interesting
here-
is
that
this
conversation
is
transparent
and
this
bit
can
appear
as
an
environment
variable
that
can
only
be
seen
within
the
enclave
or
even
a
fire
in
the
file
system.
That
doesn't
actually
exist.
A
A
So
I
have
here
a
short
demo
for
you.
I
hope
you
can
see
my
screen.
It's
not
too
small.
So
here
I
have
a
terminal
that
I'm
going
to
use
to
trigger
the
spire
server.
So
nothing
special
here
then
here
I
want
to
get
the
bundle
here.
I
want
to
trigger
my
helper,
which
is
actually
a
variation
from
the
agent,
so
we
started
with
an
agent
and
make
it
made
it
a
helper.
So
it's
joining
the
server
with
a
join
token.
A
A
Then
I
can
start
my
goes
to
node
here
on
the
top.
I
have
my
terminal
that
I'm
going
to
use
for
the
sjx
workload.
So,
as
I
said,
the
the
developer
would
submit
this
configuration,
which
is
called
the
session
and
has
some
information
in
the
file
system,
and
once
he
does
that
so
here's
the
the
hash
of
this
of
this
session,
then
this
hash
is
needed
to
register
the
workload.
A
A
A
A
Let
me
just
come
back
here
and
thank
you
give
some
thanks
to
the
guys
that
contributed
so
matthias
has
been
recently
active
in
the
community
we
work
together.
I
also
would
like
to
thank
to
gustavo
and
niagara
from
hpe
for
some
feedback
crystal
fetzer
from
scontain,
so
the
maintainer
of
scone
and
also
I
got
some
very
interesting
information
from
even
a
couple
of
weeks
ago.
A
So
this
the
the
plan
is
for
this
to
be
open
source,
so
the
the
very
short
term
step
is
to
to
open
the
proposal.
So
the
request
for
comments
and-
and
then
this
code
is
now
on
a
private
git,
but
it
can
be
open.
We
just
need
to
refine
it
a
bit
more
to
also
short
term
and
of
course
I
would
like
to
hear
from
the
the
community
around
this
approach
that
we
are
using
as
mimicking
the
the
serverless
helper
push
helper
approach.