Marcus Watts [Tue, 2 Mar 2021 04:10:35 +0000 (23:10 -0500)]
rgw/kms/vault - PendingReleaseNotes pointer
The "new" transit logic requires configure changes to be
effective. Here is a pointer to the revised
documentation for those who already have data encrypted
using the previous version.
Fixes: http://tracker.ceph.com/issues/48746 Signed-off-by: Marcus Watts <mwatts@redhat.com>
(cherry picked from commit 7c3ef90913afa0d8a0c8dbfeecf5026b9c49dc6f)
Marcus Watts [Tue, 26 Jan 2021 01:49:16 +0000 (20:49 -0500)]
rgw/kms/vault - s3tests for both old and new test logic.
Test both "old" and "new" transit logic with s3tests. Does not test
migration - that will need to be done separately. I've added
a "flavor" parameter so the test logic can tell the difference
between the "old" engine and the "new" engine. The vault
keys creation logic now has options to determine whether
the keys created are exportable (needed for the old transit
engine), or not (should be the case going forward with the
new transit engine.)
Fixes: http://tracker.ceph.com/issues/48746 Signed-off-by: Marcus Watts <mwatts@redhat.com>
(cherry picked from commit e8ff0464d4ee2c418a119c03df3d313f3769ffdb)
Marcus Watts [Fri, 8 Jan 2021 22:49:20 +0000 (17:49 -0500)]
rgw/kms/vault - rework unit test logic for new transit logic.
The "new" transit logic is organized quite differently
than the old logic, so the existing unit test logic was
very broken. Additionally, it's possible to test the
input arguments and send_request() has more of them now,
so add logic to verify most of those arguments are correct.
Fixes: http://tracker.ceph.com/issues/48746 Signed-off-by: Marcus Watts <mwatts@redhat.com>
(cherry picked from commit 806a564f53a49586a30ee32d27ec3ab10b015bfa)
Marcus Watts [Tue, 5 Jan 2021 02:22:07 +0000 (21:22 -0500)]
rgw/kms/vault - document configuration for new transit logic
Using the new transit logic requires slightly different configuration.
additionally there is some backwards compatibility support, which
also needed documentation.
The existing description of how to configure hashicorp vault
to work with ceph was also incomplete. I've fleshed that out a bit,
including considerably more information on how to use configure
and use the vault secret agent with ceph.
Fixes: http://tracker.ceph.com/issues/48746 Signed-off-by: Marcus Watts <mwatts@redhat.com>
(cherry picked from commit a9edb632a5a8a768b1cbb5fa855aa22246b06c6a)
Marcus Watts [Tue, 5 Jan 2021 02:21:33 +0000 (21:21 -0500)]
rgw/kms/vault - new transit logic - fix compat logic
Teuthology passes in a vault uri that ends in /export/encryption-key/
So: we need to handle (and ignore) trailing slashes when deciding
to enable compatibility support.
Fixes: http://tracker.ceph.com/issues/48746 Signed-off-by: Marcus Watts <mwatts@redhat.com>
(cherry picked from commit eceb06022c435bfed0edde32ffb7297d55f7c252)
Marcus Watts [Tue, 8 Dec 2020 23:09:04 +0000 (18:09 -0500)]
rgw/kms/vault - "compat" option
For transit engine:
"compat" option: 0=new only, 1=old & new, 2=old only.
This is just the option parsing itself: not the actual logic
for make_key | reconstitute_key.
Fixes: http://tracker.ceph.com/issues/48746 Signed-off-by: Marcus Watts <mwatts@redhat.com>
(cherry picked from commit c190b741f88dc5e2e864c6a43689a444cc929123)
Marcus Watts [Mon, 7 Dec 2020 22:55:22 +0000 (17:55 -0500)]
rgw/kms/vault - encryption context - first part
This includes the logic to process the user provided
encryption context, turn it into "canonical json", and
to add in a default arn if it's not present.
Also present here is the start of logic to distinguish
between "prepare_encrypt" and "prepare_decrypt" at a lower
level; as "make_key" and "reconstitute_key" these will be
the functions that separately create a new datakey using
the vault transit operation, and to retrieve a previously
stored datakey.
Fixes: http://tracker.ceph.com/issues/48746 Signed-off-by: Marcus Watts <mwatts@redhat.com>
(cherry picked from commit abcf87dc52ad46a23bd4b2bca56a0af807bcf770)
Marcus Watts [Mon, 7 Dec 2020 22:53:05 +0000 (17:53 -0500)]
rgw/kms/vault - define attribute to store encryption context
For rgw sse:kms use, the aws s3 standard provides an attribute
to store the base-64 encoded canonical json "encryption context".
This should be used to vary the per-object keys used for the
actual object encryption.
Fixes: http://tracker.ceph.com/issues/48746 Signed-off-by: Marcus Watts <mwatts@redhat.com>
(cherry picked from commit 2ea143711430cb76c55479fdfbf7ba02d1fd80fb)
Marcus Watts [Mon, 7 Dec 2020 22:48:31 +0000 (17:48 -0500)]
rgw/kms/vault - share get/set attr between rgw_crypt.cc and rgw_kms.cc
In order to pass down and manage "attrs" from crypt logic to kms
logic, it's necessary to share the functions that can get and
set strings in that structure. Eventually, I plan to have
the various engines store and retrieve a per-object "datakey" that
is encrypted (wrapped) by the named kms key.
Fixes: http://tracker.ceph.com/issues/48746 Signed-off-by: Marcus Watts <mwatts@redhat.com>
(cherry picked from commit 89959fb1946c82e48144ba29f9587932730c396b)
Marcus Watts [Mon, 7 Dec 2020 22:28:59 +0000 (17:28 -0500)]
rgw/kms/vault - relax configuration parsing for rgw_crypt_vault_secret_engine
To better manage forwards and backwards compatibility when using vault
transit for rgw object encryption (sse:kms); it is desirable to provide
parameters to control how this works. It was more attractive to overload
the existing rgw_crypt_vault_secret_engine parameter for this purpose
than to invent one or more all-new parameters.
Additionally, the enum support in the configuration parser looks like
it ought to have helpful syntax checking functionality. This is not so;
failure to provide a supported enum results in silently replacing that
with the default option, resulting in confusing and non-obvious behavior
that is not at all helpful.
This change removes the enum constraint on rgw_crypt_vault_secret_engine,
allowing for more useful messages from the rgw code, and the possibility
to also provide additional information on the same line.
Fixes: http://tracker.ceph.com/issues/48746 Signed-off-by: Marcus Watts <mwatts@redhat.com>
(cherry picked from commit 845dd67b3d0b5ee297171bba437797a18e8711ee)
Marcus Watts [Mon, 7 Dec 2020 22:20:49 +0000 (17:20 -0500)]
rgw/kms/vault - need libicu to make canonical json for encryption contexts.
for encryption, aws s3 provides an "encryption" context to vary per-object
keys. The encryption context is a base64 encoded json structure, which
must be converted to a determinstic form -- "canonical json". This
requires converting all strings to a normalized canonical form: "utf-8 nfc",
it also requires thta keys in objects be sorted in a fixed order; so some
form of sorting based on nfc.
It turns out that libicu was the best way to produce utf-8 nfc (boost also
provides a mechanism, but it has many quirks). So, here are the hooks
to pull the system libicu into the build.
Fixes: http://tracker.ceph.com/issues/48746 Signed-off-by: Marcus Watts <mwatts@redhat.com>
(cherry picked from commit 8afd92425b69c7556bda040c02833d3a4a39210d)
Marcus Watts [Wed, 3 Feb 2021 19:26:46 +0000 (14:26 -0500)]
rgw/kms/kmip - document configuration for a new feature: kmip kms
I've written up a brief description of using kmip
with ceph. Major features:
* ceph configuration.
* making keys with a "paste-in" python script.
* pointers to PyKMIP and IBM SKLM.
Marcus Watts [Thu, 12 Nov 2020 03:38:18 +0000 (22:38 -0500)]
rgw/kms/kmip - rgw / kmip test integration.
s3tests needs to know key names in order to run kms tests.
It seems desirable to have s3tests default to discovering
the names that were created by the pykmip task, and that
if there is more than one rgw connected to more than one
pykmip, that names belonging to the appropriate pykmip
instance should be used.
This logic does the following:
rgw task: save pykmip role name.
s3tests task: set kms_key (and kms_keyid2) to
these in order of priority
1 s3tests client task property ['kms_key'] (or ['kms_key2'])
2 first (second) secret created in the matching pykmip instance.
3 testkey-1 (testkey-2)
For case 2, names from the secrets have an initial "token-" stripped from them.
The assumption here is that rgw is being run with a setting such as
rgw crypt kmip kms key template: pykmip-$keyid
therefore "pykmip-" will be prefixed back onto the key before use.
Marcus Watts [Thu, 29 Oct 2020 16:04:36 +0000 (12:04 -0400)]
rgw/kms/kmip - correct documentation.
The pykmip task should be after ceph, and before rgw.
kmip needs ssl certs in order to function correctly.
Because the openssl_keys task has an indeterminate
order of execution, it is best to create the ca as
a separate task. The ca can be shared with rgw, but
real life deployments of kmip are likely to have their
own CA.
In order to create kmip secrets, a client certificate
is necessary, so must be supplied to the pykmip task.
Marcus Watts [Thu, 29 Oct 2020 03:40:58 +0000 (23:40 -0400)]
rgw/kms/kmip - pykmip.py needs to make keys too.
The logic to deploy pykmip in teuthology was not complete.
The necessary logic to add kmip keys was missing.
Existing logic for other key services providers could use rest based
protocols directly from the teuthology host. For kmip, it is necessary
to use a special protocol, and it is more convenient to run this directly
on the pykmip server.
Marcus Watts [Tue, 27 Oct 2020 21:16:14 +0000 (17:16 -0400)]
rgw/kms/kmip - pykmip.py should actually run pykmip.
The logic to deploy pykmip in teuthology was not complete.
While it deployed all the code and certs to run pykmip,
it didn't actually run it. This commit fixes that.
Marcus Watts [Fri, 23 Oct 2020 23:07:09 +0000 (19:07 -0400)]
rgw/kms/kmip - python3 changes for testing.
python3 requires different imports and there's a different
way to get at the first element in a view.
This is to match changes introduced in the rest of ceph in these
commits: 24e7acc261a4d7258ea7fdcd
Marcus Watts [Sun, 16 Feb 2020 02:08:29 +0000 (21:08 -0500)]
kmip: first pass at implementation logic.
This implements SSE-KMS for the radosgw using kmip.
This uses symmetric raw keys with a name attribute in kmip,
so providing the same functionality as the "kv" key store
in hashicorp vault.
Kefu Chai [Sat, 6 Mar 2021 16:32:42 +0000 (00:32 +0800)]
.github: correct the regex in mileston workflow
also use pull_request_target event so the action is run in the
context of the base of the pull request. this helps us to overcome
the "Resource not accessible by integration" issue where the action
is run in the context of the pull request.
Sage Weil [Mon, 8 Mar 2021 15:42:59 +0000 (09:42 -0600)]
Merge PR #39856 into pacific
* refs/pull/39856/head:
qa/distro/ubuntu_20.04_podman: Avoid getting asked
qa/suites/rados/cephadm: drop centos/rhel cephadm tests for the moment
qa/sites/rados/cephadm/thrash: rename 3-tasks.yaml/ -> 3-tasks/
qa/suites/rados/cephadm: adjust distros
qa/suites/upgrade: use kubic; test all distros
qa/suites/rados/cephadm/upgrade: use kubic on centos
qa: new kubic distro files; use kubic podman for centos/rhel
qa/suites/rados/cephadm: Add 20.04 podman:testing
Kefu Chai [Sat, 6 Mar 2021 07:43:33 +0000 (15:43 +0800)]
cmake: make the linkage to pmem::pmemobj public
tools/ceph-dencoder/rbd_types.cc includes Types.h which in turn includes
libpmemobj.h via librbd/cache/pwl/Types.h. and ceph-dencoder pulls in the
rbd_type.cc's linked libraries by linking against rbd_types. but before
this change, rbd_types links against pmem::pmemobj as a PRIVATE library.
so, if we want to pull in rbd_types linkage we should always link
rbd_types as a PUBLIC library. as rbd_types include libpmemobj.h in its
header file.
Kefu Chai [Sat, 6 Mar 2021 04:22:39 +0000 (12:22 +0800)]
cmake: link libpmemobj against libpmem
libpmemobj should link against libpmem, but, in CMake, imported library
does not allow PRIVATE linkage. so pmem::pmem is added to the list of
INTERFACE_LINK_LIBRARIES.
Kefu Chai [Fri, 5 Mar 2021 06:04:23 +0000 (14:04 +0800)]
cmake: support COMPONENTS param in Findpmem.cmake
add two components: pmem and pmemobj to this package. so we can find
them and link against them in a more intuitive way.
before this change the COMPONENTS parameter passed to
find_package(pmem ...)
is dropped on the floor and ignored.
after this change, it is checked and taken into consideration.
also, in this change, the exposed variables are renamed from
PMEM_* to pmem_*
to be consistent with the package name. it's encouraged to be consistent
with the package name when it comes to the INCLUDE_DIR and LIBRARIES
variable names.
Sage Weil [Wed, 3 Mar 2021 14:14:29 +0000 (08:14 -0600)]
qa: new kubic distro files; use kubic podman for centos/rhel
The current centos/rhel version of podman (2.2.1) is broken.
- create new qa/distros/podman/* files that install kubic podman
- include centos/rhel variants
- adjust cephadm jobs to use new yaml files
- remove old qa/distros/all/*_podman.yaml files
Sage Weil [Thu, 4 Mar 2021 21:08:22 +0000 (15:08 -0600)]
Merge PR #39737 into pacific
* refs/pull/39737/head:
mgr/DaemonServer: osd ok-to-stop: return json when there are unknown PGs
doc/man/8/ceph: document --max option
src/test/osd/safe-to-destroy: adjust test
ceph: print command output to stdout even on error
mgr/DaemonServer: include details in 'osd ok-to-stop' output
mgr: add --max <n> to 'osd ok-to-stop' command
mgr: relax osd ok-to-stop condition on degraded pgs
Sage Weil [Thu, 4 Mar 2021 18:49:37 +0000 (12:49 -0600)]
Merge PR #39736 into pacific
* refs/pull/39736/head:
crush/CrushWrapper: rebuild shadow tree on 'osd crush reweight-subtree'
crush/CrushWrapper: update shadow trees on update_item()
Sage Weil [Thu, 4 Mar 2021 13:35:24 +0000 (08:35 -0500)]
mgr/DaemonServer: osd ok-to-stop: return json when there are unknown PGs
In 791952cc01201010f298033003ba52374cc0159f we switched to return JSON
both on success and fail to describe which PGs are affected or are blocking
the ability to stop/restart OSDs. Do the same for the case where
some PG states are unknown (i.e., just after a mgr restart) so that
the cephadm upgrade process can unconditionally expect a JSON result.
Nathan Cutler [Mon, 1 Mar 2021 11:07:29 +0000 (12:07 +0100)]
rpm: use PMDK system libraries on SUSE
As of a49d1dbb32e2436ff2836a85b2fa84418f0a5fff, when the rbd_rwl_cache and
rbd_ssd_cache bconds are enabled and WITH_SYSTEM_PMDK is disabled (as it is by
default), the RPM build attempts to
git clone https://github.com/ceph/pmdk.git
but of course that won't work in the OBS, where the build workers have no
Internet connectivity.
Fortunately, the openSUSE/SLE versions targeted by Ceph master and pacific ship
the necessary PMDK libraries as RPM packages.
Sage Weil [Thu, 18 Feb 2021 14:27:49 +0000 (08:27 -0600)]
mgr/devicehealth: extract+store wear level from metrics scraping
When we scrape and store health metrics for a device, extract the wear
level from the JSON. If present, also store it in the config-key
per-device metadata.
Sage Weil [Mon, 8 Feb 2021 18:53:24 +0000 (12:53 -0600)]
common/blkdev: collect non-SMART data too
Call smartctl with -x instead of -a:
-a, --all
Prints all SMART information about the disk, or TapeAlert infor‐
mation about the tape drive or changer. For ATA devices this is
equivalent to
'-H -i -c -A -l error -l selftest -l selective'
and for SCSI, this is equivalent to
'-H -i -A -l error -l selftest'.
For NVMe, this is equivalent to
'-H -i -c -A -l error'.
Note that for ATA disks this does not enable the non-SMART
options and the SMART options which require support for 48-bit
ATA commands.
vs
-x, --xall
Prints all SMART and non-SMART information about the device. For
ATA devices this is equivalent to
'-H -i -g all -g wcreorder -c -A -f brief -l xerror,error -l
xselftest,selftest -l selective -l directory -l scttemp -l scterc
-l devstat -l defects -l sataphy'.
and for SCSI, this is equivalent to
'-H -i -g all -A -l error -l selftest -l background -l sasphy'.
For NVMe, this is equivalent to
'-H -i -c -A -l error'.
projects / ceph.git / log