Project

General

Profile

Bug #17849

ceph-disk --dmcrypt create must not require admin key

Added by Joshua Schmid about 1 year ago. Updated 11 months ago.

Status:
Resolved
Priority:
Urgent
Assignee:
Category:
-
Target version:
-
Start date:
11/09/2016
Due date:
% Done:

0%

Source:
Community (dev)
Tags:
ceph-disk, osd-lockbox, dmcrypt
Backport:
jewel
Regression:
No
Severity:
2 - major
Reviewed:
Affected Versions:
ceph-qa-suite:
Release:
Needs Doc:
No

Description

Creating a encrypted OSD falls back to the key-manangement-mode 'ceph-mon v1', which will upload the en/decryption key to the monitor

As the initial upload of the key (ceph config-key put) requires an admin keyring the process fails.

Most likely linked to: https://github.com/ceph/ceph/pull/9345

[logs attached]

ceph.log View (12.1 KB) Joshua Schmid, 11/09/2016 05:26 PM


Related issues

Duplicated by Ceph - Bug #17833: missing key-management-mode in ceph.conf after default deployment Duplicate 11/09/2016
Duplicated by Ceph - Bug #16755: ceph-disk: encryption assumes admin key is present Resolved 07/20/2016
Copied to Ceph - Backport #17926: jewel: ceph-disk --dmcrypt create must not require admin key Resolved

History

#1 Updated by Owen Synge about 1 year ago

This bug has been discussed on the ceph-devel mailing list in thread:

"Understanding encrypted OSD's and cephx"

The summary of this is (as presented by Sage):

and instead define a new monitor command to do all of this in one go.
For example, 'osd bootstrap' could take the necessary arguments (e.g., the
uuid and local key) and in one step set up the various keys for you. I
think that's going to be the most maintainable and sane solution going
forward.

I (Owen Synge) would like to add that I feel a need to prevent replay attacks and propose:

Using the trigger of OSD registering to prevent replay attacks, seems
like a better compromise than making each command only work once, so
setup can be repeated until success, and then since replay is prevented
other keys cannot be exposed.

#2 Updated by Owen Synge about 1 year ago

Am currently testing a work around for the test suite:

https://github.com/SUSE/ceph-qa-suite/tree/wip_dmcrypt_admin_workaround

#3 Updated by Loic Dachary about 1 year ago

  • Project changed from devops to Ceph
  • Subject changed from osd-lockbox 'ceph config-key put' missing keyring to ceph-disk --dmcrypt create must not require admin key
  • Category deleted (ceph-disk)
  • Status changed from New to Verified
  • Assignee set to Loic Dachary
  • Priority changed from Normal to Urgent
  • Target version deleted (v10.2.5)

#4 Updated by Loic Dachary about 1 year ago

The bootstrap-osd could have permissions to ceph config-key put/get ( https://github.com/ceph/ceph/blob/master/src/ceph-disk/ceph_disk/main.py#L3691 ) and the OSD could have permission to only ceph config-key get its own uuid.

#5 Updated by Loic Dachary about 1 year ago

  • Status changed from Verified to Need Review

#6 Updated by Loic Dachary about 1 year ago

  • Backport set to jewel
  • Severity changed from 3 - minor to 2 - major

#7 Updated by Loic Dachary about 1 year ago

  • Duplicated by Bug #17833: missing key-management-mode in ceph.conf after default deployment added

#8 Updated by Loic Dachary about 1 year ago

  • Priority changed from Urgent to Immediate

#9 Updated by Loic Dachary about 1 year ago

  • Status changed from Need Review to Pending Backport

#10 Updated by Loic Dachary about 1 year ago

  • Copied to Backport #17926: jewel: ceph-disk --dmcrypt create must not require admin key added

#11 Updated by Ken Dreyer about 1 year ago

I noticed a somewhat-related ticket today: #16755

#12 Updated by Loic Dachary about 1 year ago

  • Duplicated by Bug #16755: ceph-disk: encryption assumes admin key is present added

#13 Updated by Sage Weil about 1 year ago

  • Priority changed from Immediate to Urgent

#14 Updated by Nathan Cutler 11 months ago

  • Status changed from Pending Backport to Resolved

Also available in: Atom PDF