ceph-disk --dmcrypt create must not require admin key
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
#1 Updated by Owen Synge about 2 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
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 2 years ago
Am currently testing a work around for the test suite:
#3 Updated by Loic Dachary about 2 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 (
- Status changed from New to Verified
- Assignee set to Loic Dachary
- Priority changed from Normal to Urgent
- Target version deleted (
https://github.com/ceph/ceph/blob/master/src/ceph-disk/ceph_disk/main.py#L2381 should not require admin rights.
#4 Updated by Loic Dachary about 2 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.