Project

General

Profile

Actions

Bug #17833

closed

missing key-management-mode in ceph.conf after default deployment

Added by Joshua Schmid over 7 years ago. Updated over 7 years ago.

Status:
Duplicate
Priority:
Immediate
Assignee:
Category:
-
Target version:
-
% Done:

0%

Source:
Community (dev)
Tags:
ceph-disk, osd-lockbox, dmcrypt
Backport:
Regression:
No
Severity:
3 - minor
Reviewed:
Affected Versions:
ceph-qa-suite:
ceph-disk
Pull request ID:
Crash signature (v1):
Crash signature (v2):

Description

If you depoloy a cluster with the --dmcrypt option, without specifically setting the key-management-mode in the ceph.conf ceph-disk will complain about a unknown key-management-mode in the ceph-disk systemdservice logs [*attached]

Looking at the code tells me that ceph-disk expects a k/v here unlike during the creation phase where ceph-disk falls back to the default(ceph-mon v1).

source: https://github.com/ceph/ceph/blob/master/src/ceph-disk/ceph_disk/main.py#L1150

adding key-management-mode = ceph-mon v1 obviously solves that issue.

That shouldn't happen in the first place as it should be written to the ceph.conf:

source: https://github.com/ceph/ceph/blob/master/src/ceph-disk/ceph_disk/main.py#L2408


Files

ceph-disk.log (3.53 KB) ceph-disk.log Joshua Schmid, 11/09/2016 10:55 AM

Related issues 1 (0 open1 closed)

Is duplicate of Ceph - Bug #17849: ceph-disk --dmcrypt create must not require admin keyResolvedLoïc Dachary11/09/2016

Actions
Actions #1

Updated by Owen Synge over 7 years ago

What I have learnt so far:

I have been trying to get to grips with understanding cephx and
encrypted OSD's. WRT this bug:

http://tracker.ceph.com/issues/17833

Please correct me here if I am wrong:

Installing a encrypted OSD with ceph-deploy as:

ceph-deploy osd create --dmcrypt ceph-node3:vdc

Will fail unless you first run:

ceph-deploy osd admin ceph-node3

I have been digging further:

(1) Encrypted OSD's are mounted using a key.
(2) This key is retrieved from the mon, using a cephx key.
(3) This cephx key is generated with the capability to retrieve the key
from the mon.

The reason being the admin key is needed is to make keys with correct
capabilities.

To set this up I have played with the command.

With the admin key you can:

/usr/bin/ceph --connect-timeout 20  config-key list
/usr/bin/ceph --connect-timeout 20 config-key put key value
/usr/bin/ceph --connect-timeout 20 config-key get key value

So we dont want to put the admin keyring on the OSD's with encrypted
OSD's as all encrypted OSD keys can be retrived using the admin keyring.

So I then looked at locking down the capabilities:

I can generate a key with only the ability to get a single key:

/usr/bin/ceph auth get-or-create \
client.osd-lockbox.d967ec85-4bd5-44c5-b20c-fc6864f6c7c0 \
mon 'allow command "config-key get" with key="Key_name"' \
> /tmp/foo

I can then use this key to get the key's value:

/usr/bin/ceph --keyring /tmp/foo  --name \
client.osd-lockbox.d967ec85-4bd5-44c5-b20c-fc6864f6c7c0 \
config-key get Key_name

I can also create a key that can only place values for a key:

/usr/bin/ceph auth get-or-create client.bar mon \
'allow command "config-key put"' > /tmp/bar

And this can upload to that value:

/usr/bin/ceph auth get-or-create client.nting mon \
'allow command "config-key put" with \
key="Key_name"'

And it can only set this value:

/usr/bin/ceph --connect-timeout 20 --keyring /tmp/bar --name \
client.bar config-key put Key_name Key_value

I can also use the mon keyrign ratehr than the admin key to create these
keys:

/usr/bin/ceph --connect-timeout 20 --keyring \
/var/lib/ceph/mon/ceph-ceph-node1/keyring \
--name mon. auth get-or-create client.jam mon \
'allow command "config-key put" with \
key="Key_name"'

So it seems to me, that we can potentially resolve bug:

http://tracker.ceph.com/issues/17833

Without ever putting the admin key or similar high privileged key on an
encrypted OSD node.

Now where does this leave us:

(1) We either continue to expect the admin keyring to exist.
(2) We use locked down keys on the OSD nodes.

Following option (2) We can take 1 of 2 approaches:

(A) ceph-deploy shoudl set up the encryption key and value on the mon
node, generate a value readonly key to the OSD node then deploy the
encrypted OSD.
(B) ceph-deploy should set up a read and write keys for the OSD
encryption value, then ship these to OSD node to deploy the OSD, then
remove the write key.

In both these cases ceph-deploy will need to contact the osd node, get
the partion UUID, process this on the mon node, then finish the process
of deploying an encrypted OSD on the OSD node.

Option (A) seems simpler here.

Does anyone see a better way assuming (2)?

Actions #2

Updated by Owen Synge over 7 years ago

Ops my comment was for the wrong bug, this is the target bug -> http://tracker.ceph.com/issues/17849

Actions #3

Updated by Sage Weil over 7 years ago

  • Priority changed from Normal to Immediate

The proposal is to do a quick workaround for kraken, where you are required to push an admin key to the osd host.

The proper fix would be a new set of mon 'bootstrap' commands that do exactly the right set up key setup tasks, based on the boostrap-osd profile, and nothing else, atomically and securely.

Actions #4

Updated by Loïc Dachary over 7 years ago

  • Project changed from devops to Ceph
  • Category deleted (ceph-disk)
  • Status changed from New to Duplicate
Actions #5

Updated by Loïc Dachary over 7 years ago

  • Is duplicate of Bug #17849: ceph-disk --dmcrypt create must not require admin key added
Actions #6

Updated by Ken Dreyer over 7 years ago

I noticed a somewhat-related ticket today: #16755

Actions #7

Updated by Loïc Dachary over 7 years ago

  • Target version deleted (v10.2.5)
Actions

Also available in: Atom PDF