►
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.
Cloud-native security in Rust with Keylime - Lily Sturmann, Red Hat
Keylime is a CNCF hosted, open source project that provides a highly scalable remote boot attestation and runtime integrity measurement solution. In early 2021, the Keylime team is wrapping up porting a key component of Keylime, the remote node cryptographically proving its security, from Python to Rust. This session presents an overview of Keylime with a focus on Rust as natural fit for this cloud-native security project.
A
A
A
A
So
now,
if
you
imagine
that
you
have
many
machines
with
a
similar
stack,
even
remote
machines
in
the
cloud,
this
problem
compounds
so
especially
when
you're
running
in
the
cloud
or
on
a
remote
machine,
you
often
have
even
less
control
over
these
various
stack
layers,
because
you
may
not
be
in
charge
of
all
of
them.
You
may
not
have
control
over
all
of
them.
A
So
if
you
are
running
a
remote
machine,
it
would
be
great
to
know
if
you
should
trust
these
layers,
both
at
boot
time.
So
you
want
to
know
that
you're
booting,
the
machine
that
you
expect
in
the
state
that
you
expect
as
well
as
during
runtime.
You
want
to
know
that
the
code
that
you're
running
is
running
as
expected
in
the
same
environment
that
you
expect
to
run
it
in
and
that
no
bad
actor
has
executed
some
malicious
script
on
this
machine.
A
So
what
you
see
here
is
a
simple
depiction
of
the
key
lime
setup
on
the
left.
You
see
the
remote
machine,
which
is
also
called
the
node
or
agent,
and
this
is
the
machine
that's
going
to
prove
its
trust
to
the
key
lime
system.
So
you
can
imagine
it
running
this
huge
tech
stack
layer
that
you
saw
in
the
previous
slide.
A
A
The
machines
on
the
right
hand,
side
don't
need
a
tpm.
These
are
components
responsible
for
verifying
the
state
of
the
machine
on
the
left
here,
they're
called
the
verifier
and
the
registrar,
and
these
components
could
be
running
on
a
machine
on
premises,
for
example,
so
they're
communicating
with
the
agent
over
on
on
an
untrusted
network,
and
this
is
completely
fine.
A
It
allows
for
encrypted
payloads
to
be
delivered
to
that
remote
machine
after
the
machine
has
attested
its
state
through
use
of
the
tpm,
and
it
offers
a
revocation
framework.
So,
in
the
case
of
that
malicious
script,
I
mentioned
before
that,
node
could
be,
for
example,
removed
from
the
cluster
automatically.
A
But
I
just
wanted
to
give
an
overview
of
this
architecture
so
that
you
have
some
context
for
which
portion
we
chose
to
port
to
rust
and
spoiler
alert.
It
is
the
the
agent
component
so
that
remote
and
the
reason
that
this
component
was
chosen
is
basically
because
it's
a
smaller
self-contained
component.
You
see
there
are
multiple
components
over
on
the
right
and
we're
open
to
potentially
porting
more,
but
we
just
chose
to
start
with
the
agent
for
the
first
part.
A
So
keylime
is
actually
already
available
as
an
rpm
in
developer
preview
in
fedora,
which,
if
you
don't
know
fedora,
is
a
linux
distribution
developed
by
the
fedora
project
and
at
red
hat.
We
have
a
philosophy
of
upstream
first,
so
we
want
to
contribute
directly
to
open
source
upstream
code
bases
and
build
community
around
those
code.
Bases
and
fedora
is
one
example
of
working
with
an
open
source
community
in
this
way.
A
A
At
a
very
high
level,
it's
meant
to
be
a
read-only
operating
system
in
the
sense
that
all
installed
programs
are
defined
by
a
single
commit
hash,
and
this
commit
hash
basically
describes
everything
that
is
installed
on
the
system.
So
the
system
can
be
atomically,
upgraded
or
rolled
back
to
a
particular
hash,
and
this
can
make
it
a
lot
easier
to
manage
a
large
number
of
these
machines
and,
as
you
can
imagine,
you're
not
going
to
want
to
be
installing
a
different
programs
that
that
the
system
doesn't
have
installed
already.
A
You
want
to
really
anchor
it
in
a
particular
commit
hash
so
that
you
know
the
state
of
the
system
so
for
this
fedora
core
os
use
case.
If
you
want
to
package
a
program
for
this
type
of
distribution,
you're
going
to
want
to
know
all
the
dependencies
ahead
of
time,
you're
going
to
want
the
program
to
be
very
self-contained
because
we're
not
going
to
want
to
be
updating
the
os
to
install
new
dependencies
when
the
program
is
running
and
fedora
core
os
also
tries
to
be
very
minimal
in
its
dependency
tree.
A
A
Now,
for
the
big
reveal,
the
language
that
was
chosen
was
rust
and,
in
addition
to
being
a
compiled
language
that
we
can
create
a
self-contained
binary,
it
had
multiple
other
advantages
as
well,
and
some
of
you,
rust
fans
might
already
know
some
of
these
things
about
rust.
It
has
better
performance
than
some
other
languages,
because
it
doesn't
have
garbage
collection,
for
example,
and
also
for
us,
especially
as
a
security
project.
A
We
had
a
lot
of
security
considerations,
so
the
ownership
enforcement
that
rust
has
is
very
useful
in
terms
of
memory
and
thread
safety
and
the
rigorous
type
checking
from
the
compiler
avoids
unexpected
behavior
at
runtime,
which
is
very
important.
Nobody
wants
unexpected
behavior
at
runtime,
and
then
we
also
get
to
have
some
less
concern
about
side
channel
attacks,
which
is
interesting.
A
There
are
some
papers
about
this,
actually
that
I
didn't
link
here,
but
the
lack
of
garbage
collection
leads
to
more
predictable
performance,
which
could
actually
help
with
some
timing
attacks
and,
additionally,
there's
helpful
rust
ecosystem
around
security,
for
example,
there's
even
a
crate
called
timing
shield
that
is
able
to
help
you
guard
against
some
of
these
side.
Channel
attacks
now
we
haven't
used
this
particular
crate
in
our
project,
but
I
did
find
it
and
I
just
thought
it
was
interesting.
A
A
A
A
This
crate,
as
it
became
available,
which
meant
pinning
our
dependency
to
this
library
and
cargo.tomol
actually
to
the
git
repo,
the
tss,
enhanced
system,
api,
rust,
wrap
or
git
repo,
instead
of
the
officially
released
version,
which
is
also
a
cool
rust
feature
that
you
can
actually
pin
your
dependency
to
a
very
new
code
in
a
git
repo
that
was
useful
to
us
here.
As
well
so
by
using
this
library,
we
avoided
having
to
call
out
to
see
ourselves.
A
And
what
about
our
other
experiences
with
porting
to
rust?
Well,
overall,
it's
had
everything
that
we
need
in
terms
of
cloud
native
security
we've
been
able
to
have
server
client
interactions
which
the
agent
node
needs
in
order
to
communicate
with
the
verifier
and
the
registrar
over
this
untrusted
network.
A
There
are
a
lot
of
great
crates
out
there
for
this
type
of
communication.
Already
I've
just
highlighted
a
few
here
that
we've
used
like
request
as
a
client,
there's
actix
web
for
the
server
there's
zmq
and
we've
been
able
to
have
this
type
of
communication
asynchronously
between
the
components
when
we
need
it
so
also
on
top
of
rust,
safe
and
speedy
memory
management.
A
So
the
current
status,
specifically
of
the
rust
port
of
key
lime,
is
I'd,
say
it's
about.
Eighty
percent
done.
A
lot
of
the
functionality
from
the
python
agent
is
already
in
place,
so
the
agent
needs
to
be
registered
and
activated
as
part
of
the
key
lime
system
and
code
is
already
in
place
to
go
through
those
steps,
and
we
also
have
the
revocation
framework
in
place.
So
that's
if
that's
the
case
where
a
malicious
script
is
executed
on
the
node.
A
A
We've
also
got
a
slack
channel.
So
if
you
have
any
thoughts
or
questions,
we
encourage
you
to
join
that.
I
believe,
there's
also
a
bi-monthly
text-based
meeting
on
that
same
channel,
which
is
kind
of
cool,
so
you
don't
have
to
turn
on
your
video
or
or
any
of
that
kind
of
stuff.
It's
a
purely
text-based
meeting
and
I
also
thought
I
would
plug
the
tss
es
api
again.