Project

General

Profile

Bug #17849

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

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

Status:
Resolved
Priority:
Urgent
Assignee:
Category:
-
Target version:
-
% Done:

0%

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

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 over 7 years 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 over 7 years 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 Loïc Dachary over 7 years 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 12
  • Assignee set to Loïc Dachary
  • Priority changed from Normal to Urgent
  • Target version deleted (v10.2.5)

#4 Updated by Loïc Dachary over 7 years 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 Loïc Dachary over 7 years ago

  • Status changed from 12 to Fix Under Review

#6 Updated by Loïc Dachary over 7 years ago

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

#7 Updated by Loïc Dachary over 7 years ago

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

#8 Updated by Loïc Dachary over 7 years ago

  • Priority changed from Urgent to Immediate

#9 Updated by Loïc Dachary over 7 years ago

  • Status changed from Fix Under Review to Pending Backport

#10 Updated by Loïc Dachary over 7 years ago

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

#11 Updated by Ken Dreyer over 7 years ago

I noticed a somewhat-related ticket today: #16755

#12 Updated by Loïc Dachary over 7 years ago

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

#13 Updated by Sage Weil over 7 years ago

  • Priority changed from Immediate to Urgent

#14 Updated by Nathan Cutler about 7 years ago

  • Status changed from Pending Backport to Resolved

Also available in: Atom PDF