►
Description
Videos from Ceph Developer Summit: Infernalis (Day 2.1)
04 March 2015
https://wiki.ceph.com/Planning/CDS/Infernalis_(Mar_2015)
B
A
So
that's
sells
a
piece
of
the
problem
in
that
you
can
take
the
individual
OSD
disk
and
throw
it
away
and
not
worry
about
the
data
because
it's
obscured.
But
if
you
take
the
whole
server,
then
you're
still
screwed,
because
they
have
the
keys
on
the
same
server
on
a
different
disk.
So
the
goal
here
is
to
make
a
non
stupid
key
management
scheme,
that's
better
than
that's
youssef
keys.
A
A
We
already
have
all
of
most
of
the
infrastructure
sort
of
built
into
them
on,
but
do
it
in
a
way
that
you
could
swap
in
a
different
key
manager
if
you
had
some
existing
framework
that
you
wanted
to
reuse
for
some
reason,
but
for
users
who
are
justifying
SEF
Seth
gives
you
sort
of
like
a
simple
lightweight,
integrated
key
management
thing
already,
so
the
pieces
are
that
the
monitor
can
already
sort
of
store.
This
arbitrary
bits
of
key
value
data
on
the
monitor
these
via
the
SEF
configset
API.
A
You
can
get
and
set
keys,
let's
keys
and
you
can
restrict
access
those
keys
to
other
or
to
the
I,
see.
If
I
can
you
can
restrict
access
to
those
key
value
pairs
using
different
off
keys,
so
you
could
create
an
off-key
that
is
only
allowed
to
read
sort
of
a
prefix
or
a
specific
key
from
that
config
keystore,
I'm
using
the
word
key
and
like
12
different
boys,
probably
pretty
confusing.
A
So
if
we
did
this,
then
we
could
take
the
actual
DM
Krupke
Thor
it
on
the
monitor
in
this
can
feed,
config
key
storage
section
and
then
have
some
other
key.
That's
allowed
to
fetch
it
and
use
it
to
mount,
configure
DM
crypt
and
go
from
there
in
reality,
it's
a
slightly
more
complicated
than
that,
because
we
wouldn't
actually
want
to
store
the
key.
A
We
use
Lux,
just
the
Linux
something
key
system
which
means
that
it's
actually
the
key,
is
actually
stored
encrypted
on
the
disc
itself
and
the
special
locks
metadata,
and
you
have
another
key
password.
Let's
call
it
password
that
lets
you
get
that
key
that
then
decrypts,
the
damn
crypt
portion
of
the
disk
Milan
are
you
there
are
you
there
now
I.
A
A
So
we've
talked
about
this
little
bit
offline
and
on
email
and
now
I'm,
trying
to
remember
where,
where
we
ended
up.
So
your
your
suggestion
is
to
definitely
use
Lux
to
store
the
actual
DM
Kripke
and
if
I
remember
correctly,
you
could
also
store
other
stuff
in
deluxe
metadata
portion
like
a
uuid
or
something
else
is
that
true.
C
Well,
we
cannot
start
safe
any
other
data,
but
who
is
part
of
those
headers?
So
that's
probably
the
only
thank
you.
We
need
so
rich.
That's
the
identification
of
all
the
risk
and
we
compare
it
with
anything.
So
you
already
is
there
and
we
can
even
set
on
ye.
That
is
this
interface
for
death,
so
you
can
set
something
which
is
directly
there's
something
similar
event
for
GPT
partition,
Google,
IDs,
okay,
okay,.
A
So
I,
my
assumption
was
always
that
you
want
something:
that's
on
the
disk.
That's
the
let's
call
the
password
the
password
that
you
then
handle
the
monitor
that
the
monitor
says.
Oh
you're
allowed
to
get
the
actual
decryption
key
that
you
then
use
to
unlock
the
actual
game.
Kripke
that
decrypts
the
disk,
so
there
needs
to
be.
There
needs
to
be
something
that
money
OST
is
starting
up.
It
presents
to
the
monitor
to
tell
the
monitor
that
it's
allowed
to
get
get
the
real
key
and
ideally
that
that
something
is
something
that
you
can
revoke.
A
So
the
monitor
says
if
that
person
comes
along
in
the
future,
I'm
no
longer
going
to
hand
out
that
Keeks
I
know
that
that
disk
was
compromised
or
thrown
away,
or
something
like
that.
So
do
you
know
what
what
is
normally
used
in
that
context?
I'm,
not
just
by
a
word
for
it,
but
like
in
a
in
a
normal
management
world.
C
Well,
assign
know,
at
least
for
example,
for
what
I
stream
guys
something
called
volume
key
which
is
central
key
scroll.
So
it's
kisco
pocket
where
you
can
embed
the
key
and
sent
it
through
some
other.
If
you
raise
some
active
directory
or
something
like
that,
but
I'm
sure
we
won't
use
that.
So
if
you
want
something
very
simple,
let's
probably
overkill,
but
you
want
to
store
the
key
just
implying
on,
monitor
or
use
some
yeah.
A
D
So
you
wouldn't
actually
do
this,
but
hypothetically
be
something
like
on
the
on
the
monitor
it's
encrypted
twice
once
with
the
disks
local
revocable
key
at
once,
with
the
master
key,
and
you
revoke
it
by
deleting
the
one
encrypted
with
the
disk
local
keys.
That
was
that
the
kind
of
situation
you're
talking
about
yeah.
A
I
mean
at
the
situation
what
I
was
imagining
is
slightly
simpler,
so
you
would
say
you
had
at
the
ability
to
store
your
sort
of
your
token
password
thing
on
the
disk
and
you
would
you
would
identify
it
with
the
UID,
and
so
that's
like
your
token,
and
there
would
be
n
of
those
potentially
that
are
allowed
to
get
the
real
decryption
key
forgot
monitor,
and
so
you
would
issue
1
to
the
disk
when
you
create
it.
That
says
you,
mr.
A
discs
are
allowed
to
get
your
key
to
decrypt
yourself,
and
you
can
revoke
that
and
then
later
on,
you
like
recover,
you
cover
the
disk
and
you
would
issue
a
new
one
or
maybe
reuse
the
same.
One
I
don't
know,
but
if
you
revoke
it,
you
could
just
delete
that
that
issue
token.
But
if
you
are
a
super
user
on
the
monitor,
you
could
still
wish
you
a
new
one
and
you'd
still
have
you
still.
You
never
actually
delete
the
encryption
key
like
I
think
deleting
the
actual
decryption
key
for
the
Disqus
seems
dangerous.
A
C
Gwen
disk
is
missing
or
when
disk
is
still
there,
I,
even
just
to
revoke
it,
so
it
can
be
used
anymore
without
any
special
operation,
because
locks
allows
to
just
delete
all
the
keys
thought,
so
it's
still
like
divine,
but
without
without
any
key
store
there,
and
you
can,
of
course,
if
you
have
some
key
scroll
or
some
some
backup
of
the
of
the
key
you
can
unrevoked
it.
So
you
can
kind
of
insight
again,
but
I'm,
not
sure
which
case
we
are
talking
about.
D
Pt,
if
I'm
understanding
this
correctly,
the
thing
stages
suggesting
actually
replaces
what
looks
does
so
in
so
luxe
luxe
does
the
same
thing,
but
it's
by
it
generates
a
random
encryption
key
or
something
which
it
uses
to
encrypt
the
disk
and
then
at
predefined
header
points
in
the
desk.
It
stores
a
luxe
header
that
contains
encrypted
copies
of
that
encryption
key
that
are
encrypted
with
the
allowed
decryption
passwords
right
yeah.
But
it's
got
a
point
about
of
the
disk.
D
You
put
this
in
the
monitor
instead
or
you
wouldn't
actually
need
to
encrypt
them,
because
the
monitor
has
its
trusted
right,
so
instead
you'd
simply
use
authentication
to
make
a
decision
about
whether
the
incoming
token
is
allowed
to
read
it
or
not.
Yeah,
it's
not
clear
that
luxe
even
adds
anything
there
except
another
chain
that
might
but
not.
D
A
D
So
the
challenge
is
that
once
you've
lost
that,
so
there
are
two
cases
right
in
the
case
where
you
still
have
the
disk
and
you're
about
to
throw
it
away.
Then
yeah
you
can
use
Lux
to
revoke
its
own
key
and
now
the
discus
is
unreadable
score.
But
if
you
don't
physically
have
the
disc
because
it
got
stolen,
you
can't
use
locks
to
revoke
the
key,
because
Lux's
headers
are
stored
on
the
disk.
It
still
doesn't
necessarily
do
anything
for
the
person
who
has
the
disk
because
they
would
need
to
have
the
decryption
password.
D
But
if
that's
stored
in
etsy
and
they
stole
the
machine,
then
you
have
a
problem,
though
you
need
to
store
the
decryption
password
somewhere
other
than
the
server
and
the
point
at
which
you're
doing.
That
is
almost
the
point
at
which
locks
isn't
buying
you
anything
anyway,
because
you
would.
You
would
never
have
two
passwords
in
this
situation
to
unlock
the
disk,
because
there'd
be
no
point.
D
C
D
E
D
A
D
Are
two
versions
of
lux:
does
its
own
hashing
insulting
to
generate
the
to
go
from
the
password
to
the
key,
so
it
it
might
be
the
case
that
either
that
adds
strength
because
it
papers
over
problems
with
weak
passwords
which
doesn't
matter
for
us
because
we'd
be
randomly
generating
them
or
it
removes
strength
by
adding
another
weak
point
in
the
chain.
So
I
don't
know
yeah.
A
I
think
it
I
think
this
I
think
this
is
sort
of
a
red
herring.
So
I
think
that
the
real
issue
is
there
needs
to
be
the
thing
that
you
present
to
the
monitor
that
says:
you're
allowed
to
get
the
key
that
can
be
revoked
and
that
needs
to
go
somewhere.
So
if,
if
Lux
has
a
UID
that
you
can
set,
then
it
just
so
happens
that
you
IDs
are
16
bytes
right
and
the
asf
X
keys
are
also
16
bytes.
E
A
A
So
the
way
that
the
monitor
yeah
right
so
suffix
lets
you
set
and
off
capability
that
lets
you
access
like
a
specific
key,
for
example,
the
decryption
key
for
DM
crypt.
A
Is
stored
encrypted
in
the
OST
directory
on
talked
out
a
lot
to
my
15
Crypt
is
encrypted
yeah.
So
this
is
the.
This
is
the
thing
on
the
outside
yeah
right,
so
luxe
might
provide
a
convenient
place.
The
clucks
metadata
area
might
be
a
convenient
place
to
just
stash
that
thing
that
we
can
set.
I
mean
it's
like.
A
That's
it's
16
bytes
is
the
actual
key,
but
once
you
pat
it
out
with
all
the
other
stuff,
that's
in
the
entity
key
structure,
it's
like
your
cryptic,
restructure,
its
probably
30
bytes,
or
something
and
usually
gets
base64
encoded,
so
there's
a
little
string,
but
we
just
need
to
put
that
somewhere.
Basically,.
A
C
A
C
C
D
C
Right,
well,
yes,
that's
all
security,
compare
it
with
some
identifica
or
some
key
for
the
for
the
questi.
So
still
you
can
generate
something,
and
you
hey
purposes
from
something
here
about
it.
A
Well,
it
sounds
like
it
sounds
like
you're,
assuming
that
there's
some
there's
some
like
a
host
level
authentication,
so
you
know
that
this
particular
server
is
allowed
to
be
presenting
it
so
like
the
way
that
the
the
way
that
nikki
vanish
and
controls
access
to
the
key
is
using
this
secret
right.
It's
not
it's
not
host
based.
It's
not
anything
else.
There's
like
there's
a
secret
that
you
presented,
monitor
that
says:
I'm
allowed
to
get
the
decryption
key.
A
Winner,
this
is
the
key
that
you
authenticate
with
the
monitor
with
that's
the
thing:
there's
no
host
level
will
they
see
something
right
so
when,
when
assuming
everything's
decryption
you're
starting
up
the
OST
authenticates
with
its
key
that
its
stores
inside
the
file
system,
for
example,
if
you're
an
admin
you
authenticate
with
the
key,
that's
in
at
CCF
keyring,
but
when
you
are
an
encrypted
disk
in
order
to
get
your
decryption
key,
you
need
to
authenticate
with
something
right.
It's
not
there's!
No,
there's!
No
like
global
host
property.
A
That
says
that
we
could
make
one
I
guess
that
that's
another
option
like
you
could
say
that
this
any
disk
that
appears
on
this
host
is
allowed
to
get
access
to
the
key.
But
then
that
doesn't
work
because
then
the
the
host
would
have
to
be
able
to
access
any
OSD
right
and
if
a
single
compromised
dos
do
you
can
get
corruption
keys
for
any
other
disk
in
the
entire
system.
That's
that's
a
big
vulnerability
like
you
want
to
do
you
want
to
narrow
the
scope
as
much
as
possible,
so
you
sort
of
there.
D
A
A
It
just
has
to
be
something
that
isn't
publicly
shared
beyond
that
host.
Like
has
to
be
something
that
you
can.
You
can
look
at
end
of
whatever,
but
it
yeah,
but
I
think
the
the
UID
on
the
partition
is
the
OS
duid,
that's
also
in
the
OSD
map.
What
I
think
I'm
not
sure
I'm,
not
sure
about
that,
but
I
think
that's
the
case.
So
it
would
be
nice
if
there
was
just
a
separate
space.
That's
I
mean
maybe
okay,
so
that's
possibility
one.
A
Maybe
that
would
just
work,
maybe
the
maybe
the
GPT
label
uid
can
be
used
as
the
key
make
sure
it's
not
sure
y
on
the
host
I'm
afraid
it
might
be,
though,
that's
that's
a
problem
because
there's
this
FS
ID
well
cuz.
If
I
can
carry
out
sorry
I
understand.
No,
I'm
not
I'm
not
sure.
If
that
matches
the
partition
label,
you
ID
matches
the
actual
internal
OSD
uid,
okay
and.
D
F
D
A
C
Can
I
can
I
have
a
question
you
re
you
are
talking
about
or
whatever
your
ID
I
either
it's
GPT
partition,
ID
or
rocks
ID.
It's
not
a
secret
for
other
processes.
It's
actually
universes
it
and
you
can
see
it
clearly
in
def
uid.
Does
it
this
by
UIC
soo?
So
whatever
I
am
so
I
think
you
cannot
use
that
as
some
secret
key.
Oh
yeah,.
D
A
A
So
I
think
it's
something
that
only
route
on
the
host
with
the
disk
can
access
is
I,
think
the
ideal
situation,
because
that's
when
you're
already
screwed.
So
if
that's
the
case,
then,
if
there's
somewhere
in
the
lux
header,
where
we
can
soar
something
that
only
route
can
get
at
that
isn't
parsed
by
you
Devon
putting
sisal
eorge,
I.
C
D
A
D
A
Even
if
even
if
it's
different,
then
any
non
root
user
on
the
system
can
also
see
all
the
you
at
ease
because
they're
in
dev
disk.
So
ideally
it
would
be
something
that's
just
stored
in
a
random
sector
on
the
disk
or
something
else
that
requires
somebody
to
actually
be
able
to
read
the
raw
block
device.
In
order
to
read
it
mm
so
I
mean.
A
C
And
has
two
different
parts:
first
part
is
visible
header,
which
is
passed
by
block
ID
and
so
on.
There
is
the
UI
distort
and
some
visible
parameter
for
encryption,
and
then
there
are
key
slots
that
are
actually
eight
key
slots
and
there
are
encrypted,
and
it's
actually
contains
the
real
encryption
key.
Oh
so.
A
E
E
C
Sourcing,
good,
that's
something
which
is
not
possible
with
conversion,
because
there
is,
if
you
have
enabled
key
slot,
only
the
encryption
key.
It
can
be
stored
there
for
a
conversion,
because
I,
the
part
of
the
part
of
the
unlocking
is
that
there
is
some
kind
of
chicks
on.
So
you
enter
password,
it
will
iterate,
it
will
decrypt
that
and
it
will
check
if
the
password
it
decrypt
it
key
is
correct.
If
not
correct,
it
will
just
fail.
So
you
cannot
store
everything
they
are
just
randomly
so
I'd
be
at
work.
C
A
A
E
A
C
We
can
yes,
we
can.
We
can
use
that
on
Heather
and
defend
attached
header
and
store
something
there
that
that's
possible,
but
yeah
that
could
be
could
be
done.
You
can,
you
can
have
just
just
a
file
or
some
different
partition
just
with
dogs
under
weather
and
store
something
kinky
slow,
but
it
seems
to
me
like
over
can
be
complicated
here.
C
A
A
A
C
F
A
A
D
Need
to
have
it
both
it
and
the
you.
You
need
to
have
both
it
and
the
disc
to
do
anything,
and
also
the
monitor,
isn't
going
to
use
different
encryption
keys
for
each
one
of
these
or,
if
it
does
it'll
be
generated
so
like
or
they'd
have
to
be
stored
in
the
same
database.
I,
don't
know
that
there's
any
real
value
in
it's
not
like
we.
It's
not
like.
A
Even
even
if
you
fetched
like
all
of
them
today
and
then
three
weeks
on
the
line,
you
got
the
disk
like.
Yes,
you
can,
you
can
put
the
two
together,
but
you
know
you
guys.
The
only
thing
that
prevents
that
is
that
you
would
rotate
them,
and
this
actually
has
everything
that
we
need
to
rotate
it,
because
bags
can
be
changed
too
fast
too,
and
the
lux
thing
comes.
A
Will
generate
a
completely
random,
you
know
32
32
bytes
of
right.
You
could
do
I
think
in
reality.
Nobody
probably
would
do
that,
but
you
could.
If
you
were
worried
that
somebody
dumped
a
copy
of
all
of
the
stuff
on
the
monitor
and
at
some
future
date
they
might
steal
a
disk.
Then
you
could
go
through
and
rotate
all
these
and
you
would
be
protected
again.
A
A
F
A
F
F
F
F
A
C
Don't
like
storing
any
key
implying,
but
here
it's
probably
the
simplest,
cheapest
way
and
I
expected
in
some
in
some
corporate
configuration
there.
Maybe
it
will
be
replaced
by
some
real
key
storage
like
something
so
so
we
should
probably
have
it
as
some
real
photo
need
interface
book
instead
of
storing
Kiki
in
implying
you
just
call
some
key
management
system
or
something
like.
D
C
Can
have
some
encrypted
key
storage
and
just
populate
on
the
start.
You
have
to
decrypt
it
somehow
so
still
have
some
key,
but
Papa
write
it
to
some
keyring
like
karna,
recurring
or
so,
where
it
basically
is
designed
for.
Storing
the
TV
when,
when
are
in
the
system,
but
but
for
simplicity,
I
think
that
the
first
implementation
probably
should
be
essentially
hear
what
the
probably
storing
in
plain
text
in
files
is
that
you
never
know
where
it's
coco
peat
when
first,
if
file
system
is
doing
something
you
can
manipulate,
is
with
that.
A
D
The
it
seems
to
me
the
only
advantage
encrypting
the
key
is
this
is
the
specific
case:
we've
lost
them
on
disc,
but
they
don't
have
access
to
them
on
to
some
other
piece
of
bond
configuration.
So
you
could
provide
the
monitor
with
the
decryption
key
for
all
of
these
things,
that
start
up,
which
it
just
uses
and
doesn't
write
down
and
that
that
way,
at
least,
if
you
lose
the
disk
right
but
I,
think
that's
the
only
thing
it
buys
you
and.
D
F
A
A
A
F
E
D
A
A
A
But
thereafter,
once
you're
authenticated
the
actual
commands
that
go
back
and
forth
our
scent
plain
text
over
the
wire,
so
I
think
in
order
to
sort
of
complete
this
sixer,
we
need
to
have
some
simple
encryption
that
uses
we're
yo
session
key
that
just
uses
those
AES
or
whatever,
on
the
actual
bytes
that
go
over
the
wire.
Maybe
when
there's
a
special
option
so
that
you're
only
doing
this
when
you're
doing
talking
to
the
monitor
from
the
CLI
or
whatever.
A
Think
it's
pretty
simple.
We
already
have
all
the
it
just
means
like
calling
a
s
encrypt
on
the
buffer
list
before
we
send
it
over
the
wire
like
it.
Even
it
could
even
be
just
the
everything
after
the
header.
So
like
a
better
plain
text,
maybe
it
just
as
everything
I
don't
know:
I,
don't
whatever
we
have
to
figure
out
a
layered
in,
but.