►
Description
Join us for Kubernetes Forums Seoul, Sydney, Bengaluru and Delhi - learn more at kubecon.io
Don't miss KubeCon + CloudNativeCon 2020 events in Amsterdam March 30 - April 2, Shanghai July 28-30 and Boston November 17-20! 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
Extending Kubernetes with Storage Transformers - Andrew Lytvynov, Google
Storage Transformers are invoked by the kube-apiserver just before Kubernetes resources are written/read to/from etcd. Thus, allowing developers a final chance to apply changes to resources before they are committed to disk. In this demo heavy session, we will review the architecture of storage transformers and outline the appropriate scenarios for using them as an extensibility point.
https://sched.co/NrnS
A
All
right,
let's
begin,
welcome
everyone
thanks
for
coming.
This
is
extending
kubernetes
with
directions.
Farmers.
My
name
is
Angela
Tina
and
I'm,
a
software
engineer
on
the
Google
kubernetes
engine
security
team.
So
today,
I'm
gonna
explain
to
you
briefly.
What
transformers
are
why
they
exist
in
companies
and
then
most
of
the
session
will
spend
actually
walking
through
the
guide
of
how
to
implement
one.
A
So
starting
from
a
business
problem
are
built
into
cube,
API
server
than
two
envelope
transformers
that
help
us
with
key
rotation
and
management
and
then
into
KMS
plugins
and
lastly,
I
want
to
talk
a
little
bit
about
how
we
secure
came
as
plugins
that
we
end
up
at
the
end
with
so.
Do
you
understand
what's
transformers?
Are
I
want
to
look
at
cube,
API
server
as
consisting
of
two
layers?
A
You
have
the
RPC
layer
where
your
requests
come
in
and
out
handles
authentication
authorization,
parsing
validation,
all
those
things
and
then
there's
the
storage
layer,
which
is
essentially
a
cube,
API
server,
talking
to
HDD
and
doing
any
serialization
and
deserialization
at
the
RPC
layer.
Experience
provides
you
with
extensibility
in
the
form
of
web
hooks,
so
you
may
have
heard
about
admission
web
hooks.
The
idea
is
pretty
simple:
you
just
provide
some
custom
piece
of
logic
that
is
injected
in
the
path
of
all
of
the
objects
to
traverse
the
API.
A
The
same
thing
at
the
storage
layer
is
provided
by
transformers.
So
kms
plugin
is
an
example
of
a
transformer,
but
the
idea
is
the
same.
You
inject
some
custom
logic
that
sits
in
between
your
objects
as
it
can
come
in
and
out
of
HDD
by
convention
transformers.
Look
at
all
the
data
as
a
peg
by
blobs,
while
web
hooks
look
at
them
as
actual
part
objects,
so
they
will
look
at
individual
fields
and
maybe
change
their
behavior,
maybe
mutate
the
fields,
business
of
logic.
A
Obviously,
that's
just
the
convention
transformers
are
free
to
parse
all
the
objects
as
they
come
in
and
out,
but
if
you
find
yourself
needing
to
do
that,
web
hooks
are
probably
a
better
fit
for
your
use
case.
So
I
buy
it
sake.
Russians
farmers
at
all,
Keep,
Calm,
first
of
all,
transformers,
are
someone
under
documented.
A
It's
kind
of
difficult
to
figure
out
how
the
code
base
sure
how
how
to
implement
one,
and
my
colleague
Alex
to
knock
off
Sookie,
has
spent
a
lot
of
time
working
with
transformers
for
jiggy
and
there's
some
valuable
lessons
to
be
learned
from
from
his
work.
And
finally,
with
this
sole
new
shared
knowledge.
I
want
to
encourage
some
new
contributions,
maybe
to
just
improve
the
codebase,
maybe
to
redesign
the
entire
feature,
maybe
to
implement
some
new
kinds
of
transformers
for
use
case
that
are
not
obvious
right
now.
A
The
reason
transformers
were
created
in
the
first
place
and
kubernetes
is
because,
by
default
cube,
api
server
does
not
encrypt
any
of
your
secrets
at
rest.
So
that
means
all
of
your
data
that
you
submit
to
your
api
is
starting
your
ed
CG
data
file,
encoded
in
some
binary
format,
but
it's
essentially
plaintext
and
transform
us
exist
to
solve
that
for
at
least
the
secrets
by
encrypting
them
before
starting
to
HDD.
The
reason
it's
a
problem
is,
if
you
look
at
someone,
for
example,
creating
a
new
secret
in
your
API.
A
They
send
it
to
keep
api
server,
then
cube
api
server,
encodes
that
in
some
format,
but
essentially
stores
it
in
plain
text.
So
if
an
attacker
gets
ahold
of
your
HCV
data,
they
have
access
to
all
your
secrets.
Anything
that
your
workloads
running
in
your
cluster
have
access
to
you.
You
might
think.
Well,
if
you
spend
a
lot
of
time
hardening
your
master
VMs,
your
databases,
your
API,
you
have
all
the
are
back
rules.
Everything
is
bulletproof
but
consider
this
case
for
offline
attacks.
A
We
have
a
cluster
here
where
we
have
a
credential
stored
in
our
HDD.
That
is
just
a
credential
to
authenticate
to
some
remote
database
that
stores
a
bunch
of
sensitive
data.
Our
attacker
comes
along,
tries
to
muck
around
with
our
VM
or
API,
and
nothing
works.
It's
indeed
like
really
hard
and
set
up
a
very
well
protected
cluster,
but
we
also
configure
our
cluster
to
do
a
daily
offline
backup
of
HDD
data
for
disaster
recovery
and
the
backup
server,
where
this
backup
hands
up
happens
to
be
not
as
well
hardened
as
your
master
VM.
A
So
if
an
attacker
gets
access
to
that,
they
can
use
the
credential
to
access
the
data
store
and
basically
it's
game
over
and
notice
that
if
I
could
didn't
have
to
compromise
your
API,
your
cluster
VMs
your
database,
nothing,
they
still
got
the
access
to
sensitive
data,
just
because
one
of
these
backup
servers
happen
to
be
not
well
hardened.
So
the
point
here
is
that
there's
many
vectors
to
accessing
and
exfiltrating
ICU
data.
A
That
may
not
be
obvious
right
away,
so
you
might
think
that
okay,
someone
got
the
dump
of
this
huge
database
of
HDD,
there's
a
bunch
of
objects,
and
it's
really
really
hard,
probably
to
parse
everything
out
figure
out
which
objects
are
secrets
or
not
figure
out
what
the
format
is
that
kubernetes
stores
the
data
in.
But
let
me
show
you
this
so
I'm
gonna
run
a
little
helper.
That
will
do
the
tacking
for
me,
but
it's
all
running
live
so
I.
A
Have
this
HDD
data
directory
dumped
from
a
running
cluster
after
a
quick
search
in
the
documentation,
I
and
know
that
members
Neb
DB
is
where
the
data
data
is
actually
stored.
So
I'm
gonna
run
the
strings
utility
on
this
file
and
streams.
Utility
is
essentially
available
on
any
Linux
distribution,
pretty
much
built
in
and
it
will
print
out
any
data
in
the
file
provided,
that's
textual,
so
anything
that's
binary
is
discarded.
Anything
that
looks
like
a
piece
of
text
will
print
out.
So
here
like
if
you
scroll
around,
you
can
see.
A
There's
some
object,
URL
looking
things
there
are
some
full
objects
in
JSON,
so
that
looks
promising
I'm
just
gonna
grab
this
output
for
a
string
secret
and
immediately
find
one
finding.
It's
called
a
DB
secret.
So
on
okay,
so
I'm
gonna
pass
the
C
flag
to
grab,
which
will
just
show
me
the
lines
around
where
this
match
was
found,
and
here
at
the
end
you
can
see
that
we
have
our
secret
name.
A
All
right,
so
hopefully,
I
kind
of
convinced
you
that
encrypting
secrets
at
rest
is
a
useful
to
do
now.
Let's
jump
into
the
main
section,
and
how
do
you
actually
implement
one?
How
do
you
create
it
if
you
have
an
idea
for
transformer,
so
this
URL
here
I
have
a
fork
of
kubernetes
where
I
built
a
transformer.
That's
following
exactly
the
same
steps
I'm
going
to
show
you
right
now.
The
steps
I'm
going
to
show
be
showing
in
the
slides
are
more
abstract.
A
I'll
just
use
some
code
snippets
for
demonstration
purposes,
but
on
this
fork
implemented
a
transformer
that
does
sm4
encryption
at
rest,
alongside
all
the
other
available
transformers
and
if
you're
not
familiar
sm4
is
an
encryption
algorithm
similar
to
AAS.
That's
has
been
designed
and
approved
by
the
Chinese
scientific
community.
A
Before
we
jump
in
the
steps
at
the
bottom
right
of
each
slide
will
be
the
exact
commit
on
that
fork
that
implements
this
step
and
also
chai.
These
are
actual
links
to
the
directories
and
files
where
the
changes
I'm
going
to
talk
I'm
going
to
talk
about
our
new
to
be
made
so
first
up.
Obviously,
we
need
to
implement
the
actual
Korell,
our
transformer,
what
it
does
and
that's
done
by
implementing
this
transformer
interface.
A
It's
pretty
simple
interface,
just
two
methods
you
get
some
data
before
or
right
after
is
being
read
from,
but
actually
being
read
from
it
CD
and
you
have
to
transform
it
back
and
same
thing
in
the
opposite
direction.
So
that's
specific
to
what
your
customer
does,
but
should
be
pretty
straightforward.
A
Next
step
transform
is
don't
really
exist
in
isolation.
Usually
they
need
some
input.
So
for
encryption
transformers
will
be
encryption
keys.
There
may
be
some
other
data
you
might
need
to
provide.
All
this
configuration
is
passed
to
cube
API
server
through
a
yellow
file
at
startup.
This
file
is
contains
an
encryption
configuration
object
and
essentially
it
lists
the
types
of
resources.
A
That's
the
transformer
applies
to
and
that
the
specific
transformers,
so
providers
is
just
a
Senate
in
fortunes
formers
here
and
here,
I
sort
of
sketched
out
what
n1
my
provider
to
look
my
transformer
to
look
like
I.
It
has
a
key
and
a
field,
some
other
type
as
input
so
now,
I
convert
that
last
chunk
into
a
go
struct
into
which
I'm
gonna
parse
out
the
mo.
A
It
should
basically
mirror
the
exact
llamo
object
that
you
expect
to
get
and
you
might
notice
there
are
two
links
to
the
files
here
and
yes,
you
need
to
implement
the
exact
same
struct
in
two
places.
You
might
also
notice
that
we're
using
JSON
tags
in
our
struct
fields,
while
we
are
parsing
out
llamo,
but
you
know
you
don't
have
time
to
make
our
code
base
make
sense.
We
just
have
transformers
too
right.
So
let's
go
next
step.
Three,
you
have
your
configuration
now.
A
You
just
need
to
register
it
as
a
possible
transformer
in
the
encryption
configuration
yeah
Malaysia
before
and
to
do
that,
you
just
add
it
to
an
existing
struct
at
the
end,
so
here
I
just
that
it
is
the
last
fields
and
the
same
two
files.
It's
pretty
straightforward
next
I
need
to
explain
what
prefix
transformers
are.
A
Prefix
transformers
exist
for
the
purpose
of
not
having
any
conflicts
between
multiple
transformers.
So
when
a
prefix
transformer
write,
some
data
to
ICD,
it
prepends
the
static
prefix,
that's
highlighted
here
to
the
data
and
then
when
it
reads
it
back,
it
actually
checks
the
prefix
strip
set.
But
if
the
prefix
does
not
match,
you
know
that
there's
some
miss
configuration
there's
something
wrong
and
instead
of
corrupt
returning
corrupt
data,
it
will
throw
an
error.
So
here
yeah
I
just
grabbed
another.
It's
your
data
file
and
the
prefix
looks
roughly
like
this.
A
So
you
register
your
prefix
in
this
console
Ock
and
the
linked
file,
and
the
cost
block
is
at
the
top
and
list
prefixes
for
all
the
other
transformers,
they're
already
existing
companies.
It's
pretty
simple!
So
last
step
we
have
our
configuration
struct,
we'll
the
inputs
for
our
transformer.
We
have
our
transformer
implementation.
Now
we
just
need
to
instantiate
that
implementation
from
the
config
in
the
linked
file.
You
create
a
new
function
that
takes
your
configuration
as
input
takes
your
prefixes
inputs.
That
would
be
a
good
place
to
validate
the
configuration.
A
So
if
you
have
any
keys,
you
need
to
parse.
If
you
have
any
other
configs
that
need
to
be
Val,
that's
a
place
to
do
it.
Then
you
instantiate
your
transformer
implementation
from
this
config
and
right
before
returning
your
Rapids
with
the
prefix
transformer.
So
it
handles
all
this
prefix
thing
for
you
so
great.
Let
me
show
you
how
that
looks
in
practice.
A
A
Here
I
have
my
encryption
configuration
that
I
passed
to
that
cluster.
You
can
see
this
has
some
four
transformer
config
field
here
and
I.
Just
give
it
a
single
key,
the
encryption
key
so
start
the
cluster
in
a
separate
tab
and
I'm
gonna
make
sure
that
it's
actually
running.
So
it's
like
running
on
my
local
host
live
I'm
gonna,
create
a
secret
I'm
gonna,
give
it
two
fields:
username
and
password
and
I'm
gonna
name
a
deputy,
be
secret,
go
on
so
I'm
just
gonna.
A
This
is
how
it
looks
like
in
Yama
when
you
print
it
out
as
a
client.
You
will
notice
that
these
fields
don't
look
like
the
actual
fields
I
set,
but
these
are
just
base
64
encoded.
So
this
basic
C
for
Dakota
is
just
password
0,
and
this
is
as
this
working
has
intended,
because
we're
not
doing
encryption
had
the
application
at
the
client
layer
so
now
that
the
API
layer
we're
doing
it
as
a
storage
layer,
so
client
should
have
no
difference
in
experience
now
for
comparison
from
the
previous
demo.
A
This
is
the
the
command
we
ran.
This
is
the
output
we
got,
so
we
got
our
username
and
password
in
plain
text
here
now
the
same
command
ran
against
this
new
cluster.
We
see
that
we
still
find
the
secrets
identifier,
but
then
we
have
our
prefix
that
I
used
for
my
transformer
and
a
bunch
of
binary
data.
That's
not
principal
and
that's
the
encrypted
data,
so
ok
great
that
works,
but
we
have
two
problems.
The
first
problem
is
that
we
provide
this
encryption
key
at
startup,
the
the
young
file.
A
So
that
means,
if
you
want
to
rotate
the
key,
you
need
to
restart
the
API
server
you
to
update
this
encryption
configuration
it's
a
lot
of
manual
work
and
it's
a
little
bit
of
API
downtime.
So
that's
not
great,
but
the
bigger
problem
is
that
our
key
is
stored
in
plain
text
on
disk,
so
the
encryption
configuration
llamó
is
passed
to
keep
api
server
at
startup
as
a
file
path
and
odds
are
that
that
file
is
stored
in
exactly
the
same
disk
or
history
or
HDD
data.
A
So
if
the
attacker
compromises
the
entire
disk,
not
just
the
directory,
then
they
have
all
the
keys.
They
need
to
decrypt
all
the
all
the
secrets
to
help
us
with
those
two
problems:
we're
gonna
use,
envelope,
encryption
and
then
evolve
transformers.
So
it's
a
bit
of
a
tricky
concept.
I'm
gonna,
walk
it
step
by
step,
so
bear
with
me.
The
idea
behind
an
OLAP
transformation
is
that
you
use
two
keys
instead
of
one
to
encrypt
every
piece
of
data.
A
When
you
actually
start
the
data,
you
encrypt
it
with
the
deck
you
encrypt
the
deck
with
the
CAC,
you
have
concatenated
those
two
parts
and
that's
called
the
envelope.
That's
what
she
actually
put
into
I'd
CD.
Well
key
encryption.
Key
lives
outside
of
outside
of
the
master
VM
completely
on
a
separate
machine
and
separate
infrastructure.
A
A
Like
encrypts,
decrypt,
sign
and
so
on,
so
the
idea
here
is
that
we
use
KMS
or
something
similar
to
host
the
qex
and
never
let
them
land
in
plaintext
on
our
master
vm
semester
only
has
these
like
encrypted
blobs
in
the
envelope,
so
that
solves
our
second
problem
of
keys
being
in
plaintext,
the
first
one
of
key
rotation
and
management
I'm,
just
gonna
walk
by
example.
So
it's
a
little
clearer,
so
we
ever
came
as
provider
with
the
CAC
and
most
EMS
providers
allow
you
to
automate
key
rotation.
A
So
here
we
have
configured
that
to
create
a
new
version
of
the
CAC.
Every
month.
When
you
write
your
first
secret
hit,
create
it
gets
its
own
Dec
Dec
one
and
then
that
one
encrypted
with
CAC
1.
If
you
create
another
secret,
you
get
a
separate,
dedicated
deck
for
every
single
secret
and
then
that
jack
is
encrypted
with
CAC
1
again
now
some
time
passes
our
automation
kicks
in.
It
creates
the
second
version
of
the
CAC.
Some
more
time
passes.
It
gets
another
version
now
at
this
point.
A
If
you
create
a
new
secret,
it
will
get
that
sound
deck
as
before
deck
three,
but
this
stack
will
be
encrypted
with
the
latest
version
of
the
CAC,
so
CAC
v3.
If
you
update
an
existing
secret,
it
will
notice
that
the
CAC
used
was
an
old
one
and
it
will
create
a
brand
new
deck
for
it
and
then
encrypt
that
deck
with
the
latest
CAC
CAC
v3.
A
So
that's
how
you
can
gradually
roll
and
update
all
of
your
secrets
to
use
the
latest
version
of
the
CAC
without
having
to
do
any
any
manual
rotation
any
restarts.
You
can
also
manually
trigger
a
secret
update
to
sort
of
indirectly
update
to
the
latest
CAC,
so
you
can
clean
up
some
older
versions,
so
that
sounds
like
it
solves
our
problem,
but
it's
pretty
pretty
complicated.
There's
a
lot
of
keys,
trying
around
a
lot
of
encoding
and
creating
envelopes
and
whatnot.
Well,
luckily,
I
don't
need
to
do
any
of
that
yourself.
A
That's
already
implemented
for
the
most
part
in
Cabernets.
It
there's
this
envelope
transformer
type
that
takes
two
pluggable
pieces
of
functionality.
It
has
the
envelope
service
and
the
base
transformer
func,
so
the
baseness
former
func
is
what's
actually
used
to
encrypt
the
data
with
a
deck
autotransformer.
We
create
the
deck
for
you
and
then
we'll
call
this
function
with
the
deck.
So
you
can
return
the
initialize
transformer
from
it,
so
you
can
reuse
the
same
transformer
from
step.
One.
The
other
part
is
the
envelope
service
and
that's
actually
an
interface.
A
It
has
just
two
two
methods
and
it's
used
to
encrypt
the
deck
with
a
CAC.
So
the
idea
is
that
the
service
is
some
sort
of
a
remote
service
that
doesn't
expose
the
CAC
to
you
in
plain
text,
but
so
we
could
potentially
implement
the
service
interface
for
a
lot
of
possible
KMS
providers
like
volt
or
amazon
key
service.
But
following
the
community's
philosophy,
we
don't
actually
want
to
put
any
third
party
and
you
vendor
code
into
the
upstream
grenades
repository
in
stats.
A
We
want
to
provide
a
standardized
extension
points
and
sort
of
hide
this
third-party
code
outside
of
the
tree
somewhere.
For
that
there
just
came
as
plugins.
The
idea
became
as
plugins
is
that
they
are
lightweight
proxies
local
proxies
on
the
master
that
expose
a
standardized
interface
that
cube
API
server
knows
how
to
talk
to,
and
then
the
proxy
does
requests
to
the
kms
provider,
using
whatever
protocol
that
provider
happens
to
be
using
they
already
built
into
kubernetes.
A
You
can
specify
the
emini
encryption
configuration
you
just
have
to
give
it
a
name
and
the
UNIX
domain
socket
to
talk
to
you
and
UNIX.
The
main
socket
is
an
actual
explicit
limitation.
You
cannot
have
a
remote
scheme
as
plug-in.
The
reason
for
that
is
this
basically
eliminates
a
problem
of
needing
to
authenticate
from
cube
API
server
to
the
kms
plugin
so,
and
usually,
there's
no
reason
to
have
a
remote
kms
plugin
anyway.
A
This
UNIX
endpoint
should
serve
a
JIRA
PC
service
that
implements
this
definition.
It's
basically
the
same
as
the
interface
we
looked
at
a
few
slides
back,
but
with
an
extra
version
method
for
just
a
metadata
just
to
visualize
it
all
together
how
the
entire
flow
works.
With
the
kms
plugin
say
your
user,
your
operator
submits
a
new
secret,
pushes
it
to
the
API
cube.
Api
server
then
generates
in
your
deck.
It
encrypts
the
data
with
the
deck.
A
Then
it
calls
the
encrypt
RPC
towards
the
Chema's
plug-in
with
a
plain
text:
deck
that
gets
proxy
over
to
the
kms
provider.
Using
that
specific
API
EMS
provider
encrypts
the
deck
with
the
CAC
returns
back
the
encrypted
blob.
That
gets
returned
back
to
the
cube,
API
server
cube.
Api
server
opens
the
encrypted
data
in
an
encrypted
deck
and
stores
that
envelope
in
a
CD.
So
nothing
unencrypted
ever
touches
the
disk
and
that
only
exists
in
the
memory
of
cube
API
server.
A
Ok,
one
like
to
other
steps
that
are
optional
by
default.
Kim
Yuna's
plugin
will
use
AES
encryption
for
Dex
so
for
encrypting
data,
but
the
deck.
If
you
want
something
else-
and
in
this
case
I
wanted
my
deck
to
be
an
SM
4
key,
you
need
to
do
a
little
bit
extra
plumbing,
so
here,
I
added
a
deck
type
field
to
the
existing
kms
configuration
and
that's
the
yellow
configuration
blob,
that's
being
parsed
and
then
I
added
a
switch
to
the
the
function
that
initializes
camus
plugin.
A
Leslie,
most
likely
you
don't
need
to
implement
your
own
kms
plug-in,
there's
plenty
of
officially
supported
plugins
from
a
bunch
of
providers
out
there,
here's
just
a
small
selection
of
them.
So
if
you
search
around,
you
can
probably
find
one
and
just
use
it.
But
if
not
you,
your
is
pretty
easy
to
implement.
A
Ok
now
you
should
roughly
understand
how
the
whole
code
bases
structure
around
transformers
how
to
implement
one.
The
last
thing
I
want
to
mention
here
is
Fred
model
for
kms
plugins
or
basically
how
to
help
secure
the
kms
plug-in.
So
the
problem
here
is
that
K
must
plug
in
touch
the
remote
game
as
service,
so
it
needs
to
authenticate
somehow
needs
to
provide
some
credential.
In
this
case.
Let's
say
it
uses
a
static
token,
that's
passed
with
a
request
for
authentication.
A
We
also
have
our
cluster
configured
to
do
a
full
disk
backup
of
the
master
for
disaster
recovery
instead
of
just
at
a
city
database.
So
it
might
be
easy
to
overlook
and
just
store
the
token
on
disk
and
plain
text
for
Camus
plug-in
to
to
read
and
use.
But
if
our
attacker
compromises
the
offline
disk
backup,
they
essentially
own
everything
they
need
to
decrypt
the
data
and
as
long
as
they
can
figure
out
this
whole
envelope
and
decryption
dance
they
they
can
get
access
to
your
secrets.
A
So
our
goal
must
be
to
not
ever
let
the
plaintext
token
touch
the
disk
and
to
do
that,
one
approach
I
want
to
propose
is
using
trusted
platform
modules
or
tpms.
If
you're
not
familiar
with
gPMs
our
little
crypto
coprocessors
they're,
usually
built
into
all
of
the
server
motherboards
as
an
onboard
ship.
A
There
are
also
virtual
versions
of
them,
so
you
can
create
a
virtual
TPM
for
every
VM
running
on
a
server,
and
the
main
idea
behind
them
is
that
they
have
a
little
region
of
protected
memory
and
that
memory
is
completely
isolated
from
the
host.
So
if
you
have
full
root
privileges
or
in
the
machine
or
if
you
have
compromised
the
kernel,
you
can
still
not
treat
that
memory
and
you
can
only
interact
with
it
indirectly
through
commands
that
manipulate
it.
A
A
So
we
we
cannot
put
it
directly
in
a
TPM,
but
what
we
can
do
is
we
can
use
a
encryption
key
stored
in
the
TPM
in
order
and
encrypt
the
token
with
it
before
storing
it
on
disk,
and
this
is
called
sealing
and
basically
in
order
to
unseal
the
the
token
you
need
to
be
physically
on
the
master
vmx
having
access
to
the
actual
TPM
to
get
access
to
this
key
and
decrypt
it.
You
might
think
why?
Don't
we
just
like
skip
this
whole
thing
and
use
TPM
as
a
kms?
A
The
problem
is
that
TPMS
are
really
low
powered
devices.
They
have
very
limited
memory,
so
you
can
only
start
a
handful
of
keys
there,
and
at
least
physical
TPMS
will
be
really
slow
in
encryption
and
decryption.
So
they'll
really
slow
down
your
API,
so
they're
not
a
good
fit
for
like
in
being
something
in
request
path.
A
I
want
to
encourage
anyone
to
strongly
consider
encrypting
your
secrets
at
rest,
if
you're
not
doing
it
already,
hopefully
there's
enough
evidence
that
this
is
a
problem
worth
addressing
and
also
Iyengar's
the
audience
with
the
new
information
about
transformers
to
actually
go
out
and
contribute
to
the
transformer
code
base.
Maybe
proposed
design
changes
maybe
implements
new
types
of
transformers
that
don't
only
do
secrets
encryption
and
maybe
implement
a
kms
plugin
for
a
provider
that
doesn't
have
one
already.
A
Finally,
here's
a
few
links
to
the
previous
talks
on
the
kms,
plugins
and
TPMS
from
previous
cube
cons.
That
might
be
interesting
if
you
actually
want
to
dive
into
this
deeper
and
implement
your
own
transformers
right.
Thank
you
very
much
and
if
there's
any
questions,
I
believe
we
have
a
few
minutes.
B
A
B
A
A
B
A
A
So
there's
also
something
called
like
filesystem
layer,
encryption
or
disk
encryption,
and
that
usually
is
done
by
most
cloud
providers
already
the
problem.
So
those
two
things
are
not
achieving
the
same
goals,
necessarily
their
supplemental
to
both
both
are
needed.
You,
the
thing
that
full
disk
encryption
provides.
You
is
protection
against
someone
physically
running
and,
like
stealing
your
hard
drive
like
something
running
into
the
data
center
and
grabbing
the
hard
drive
and
mounting
interviewing
data.
A
As
long
as
that,
hard
drive
can
be
put
online
in
a
data
center
and
decrypt
it
at
runtime,
which
usually
happens
with
backups
you,
you
don't
even
see
that
the
disk
was
encrypted
in
the
first
place.
You
usually
see
that
the
data
that's
like
at
a
higher
level
that
was
already
decrypted
and
provided
for
you.
So
for
this
encryption
is
a
supplemental
feature.
Now
EDD
could,
in
theory,
implement
encryption
of
its
own
just
say
like
everything
that's
reading
to
HCT
is
being
encrypted
before
it
touches
the
disk
that
could
be
done.
A
I'm
not
I'm
not
been
with
child
in
touch
with
ICD
folks
about
it,
but
I
assume
it
has
exactly
the
same
problems.
Is
that
you
have
to
specify
we'll
provide
some
key
coming
from
more
to
do
in
the
encryption?
Usually
the
problem
with
the
encryption.
A
trust
is
not
the
actual
fact
of
encryption,
but
it's
the
key
management,
that's
associated
with
it
and
theoretically
it's
you
could
implement
something
similar,
but
they
would
have
the
same
exact
problems.
Exam.
Another
reason
is
that
encrypting
everything
might
be
my
defect
performance.