Rook uses global or node-local device class configuration if device-level
configurations doesn't exist. However, after introducing device-class
level resource configuration, rook set the default value of device class.
So global or node-level device class configuration has never been used
after that.
Closes: https://github.com/rook/rook/issues/11871
Closes: https://github.com/rook/rook/issues/11826
Signed-off-by: Satoru Takeuchi <satoru.takeuchi@gmail.com>
(cherry picked from commit 3e34ebeff8)
This commit adds functionality to be able to rotate
key encryption key of encrypted PVC backed OSDs.
Necessary changes such as adding update functionality
to kms and rbac changes are made as well.
Signed-off-by: Rakshith R <rar@redhat.com>
(cherry picked from commit 71e011f731)
This commit adds support for updating secret for default KMS.
This is required for encryption key rotation.
Signed-off-by: Rakshith R <rar@redhat.com>
(cherry picked from commit b41fdfbb62)
This commit adds util functions to support encryption key rotation
such as RemoveEncryptionKeySlot, AddEncryptionKey and
ensureEncryptionKey.
Signed-off-by: Rakshith R <rar@redhat.com>
(cherry picked from commit 973723cbdd)
few functions got change as they were deprecated
for ex: ioutil.Readfile change to os.Readfile
ioutil.TempFile change to os.CreateTemp
And fixed golang-ci-lint-issues
Signed-off-by: parth-gr <paarora@redhat.com>
(cherry picked from commit a84daf9bf0)
It removes the condition that select the devices name prefixed with /dev/mapper as it is causing the ceph-volume command to fail.
Closes: #11301
Signed-off-by: ausias-armesto <ausiasarmesto@gmail.com>
Multipath devices may have an FSTYPE=mpath_member even though
a valid device for creating an OSD. The device will be allowed
in this case when creating the OSD on a PV since it is a device
specifically provisioned for the OSD.
Signed-off-by: Travis Nielsen <tnielsen@redhat.com>
During osd-prepare-job,
The encrypted device is found to be closed in some cases when
the OSD deployment has been removed manually accompanied
by any of following cases:
- node reboot
- csi managed PVC being unmounted etc
while re-opening the block to re-hydrate the OSDInfo,
the dm device `<pvc-name>-block-dmcrypt` clashes with
the one used by OSD pod which is stale by now.
This commit adds cmd to remove this stale dm device.
Error with output "No such device" is ignored.
Signed-off-by: Rakshith R <rar@redhat.com>
This commit implements this corner case during osd-prepare job.
```
The encrypted block is not opened, this is an extreme corner case
The OSD deployment has been removed manually AND the node rebooted
So we need to re-open the block to re-hydrate the OSDInfo.
Handling this case would mean, writing the encryption key on a
temporary file, then call luksOpen to open the encrypted block and
then call ceph-volume to list against the opened encrypted block.
We don't implement this, yet and return an error.
```
When underlying PVC for osd are CSI provisioned, the encrypted device
is closed when PVC is unmounted due to osd pod being deleted.
Therefore, this may occur more frequently and needs to be handled.
This commit implements the fix for the same.
Signed-off-by: Rakshith R <rar@redhat.com>
We can use LVM logical volumes and loop devices as OSD iff we specify
them in the `devices` field. If we use filters like `deviceFilter`,
these devices are not picked with a log message which let users
to specify the exact device name. It's better to mention which field
users should use in this case.
Closes: https://github.com/rook/rook/issues/11353
Signed-off-by: Satoru Takeuchi <satoru.takeuchi@gmail.com>
A new variable is added to rook-ceph-operator-config
ConfigMap to allow using loop devices for osd.
This feature is intended to be used for testing purposes only.
Signed-off-by: Shinya Hayashi <shinya-hayashi@cybozu.co.jp>
When the osd is purged, properly log the host name
that is being purged and whether the host was
removed from the crush map.
Signed-off-by: Travis Nielsen <tnielsen@redhat.com>
currently, osdSafeToDestroy check is done before
marking osd out which prevents ceph from rebalancing.
With this changes, we are moving check for
osdSafeToDestroy after osd is marked out.
Signed-off-by: subhamkrai <srai@redhat.com>
This commit changes cryptographic length for keys created
for kmip kms to 256 from 128, since it is more secure.
Signed-off-by: Rakshith R <rar@redhat.com>
LVM logical volumes are not picked by `deviceFilter`, `devicePathFilter`,
and `useAllDevices`. It's to prevent old version's users from creating
lv-backed osd during upgrading rook by accident.
It's better to clarify lvs are not picked by filters" in docs and
suggest users to use exact device name instead.
Signed-off-by: Satoru Takeuchi <satoru.takeuchi@gmail.com>
OSD on LV with metadata device is not supported. So we once we made
a fix to disallow this configuration. However, it's insuffucient
because we forgot to reset `matched` flag.
Signed-off-by: Satoru Takeuchi <satoru.takeuchi@gmail.com>
The cluster-wide encryption feature now
supports KMIP (Key Management Interoperability Protocol)
kms.
KMIP is an extensible communication protocol that defines
message formats for the manipulation of cryptographic keys
on a key management server.
For more information, refer:
https://en.wikipedia.org/wiki/Key_Management_Interoperability_Protocol
Signed-off-by: Rakshith R <rar@redhat.com>
The RGW support server side encryption with help of s3 protocol, till
now the `sse:kms` was support in which keys will be provided by the user
and but it will be saved in external management service like vault. Now
the support for `sse:s3` is added so the entire encryption key
management is performed by RGW itsels.
Signed-off-by: Jiffin Tony Thottan <thottanjiffin@gmail.com>
This commit replaces `os.Setenv` with `t.Setenv` in tests. The
environment variable is automatically restored to its original value
when the test and all its subtests complete.
Reference: https://pkg.go.dev/testing#T.Setenv
Signed-off-by: Eng Zer Jun <engzerjun@gmail.com>
Rook supports raw mode OSD in host-based cluster. So we can also
support OSD on logical volume in this kind of cluster.
Logical volumes aren't picked by filters (i.e. `useAllDevices: true`
and `device{Path,}Filter` to avoid unwanted LV consumption on upgrade.
Closes: https://github.com/rook/rook/issues/2047
Signed-off-by: Satoru Takeuchi <satoru.takeuchi@gmail.com>
With octopus coming to end of life, we remove support from
Rook for deploying Ceph Octopus and assume a min version of
Pacific v16. Any checks for octopus or earlier are removed
from the reconciles since they are obsolete.
Signed-off-by: Travis Nielsen <tnielsen@redhat.com>
Let it fail further once we run c-v activate. The error reported by LVM
could potentially ignored. If there is a failure, the c-v command will
fail anyways.
Signed-off-by: Sébastien Han <seb@redhat.com>
Return the error instead of hiding it, err could be non-nil for a lot of
reasons, eg: a canceled context or a non-existing object.
Signed-off-by: Sébastien Han <seb@redhat.com>
Once we are done cleaning up the content of the encrypted osd, let's
close the main LUKS device.
This avoids having dm devices on the system after the cleanup.
Closes: https://github.com/rook/rook/issues/10181
Signed-off-by: Sébastien Han <seb@redhat.com>
There is a corner case where an env variable populated with the prepare
job could influence and trigger some encryption code. We have an env
variable to discover whether the prepare job will encrypt a drive or not
so let's use that instead of running code as a noop and sometimes
trigger a corner case. In this scenario, the prepare job had an "IBM_"
env variable present in the OS image (IBM OS) so the setKEKinEnv()
function would get called for no reason.
Signed-off-by: Sébastien Han <seb@redhat.com>
This commits makes Rook usable on NixOS.
NixOS system holds "installed" binaries in `/run/current-system/sw/{bin,sbin}`.
The only binaries residing outside those paths are `/usr/bin/env` and `/bin/sh`.
I got a suggestion on Slack to simply add those NixOS specific paths
Signed-off-by: Krzysztof Nazarewski <3494992+nazarewk@users.noreply.github.com>
When kube authentication is used, let's clarify the error message and
hopefully lead to a better understanding on where to look for.
It could be misleading to print "token auth" when using kube auth,
although internally a token is used (the JWT from the Service
Account).
Signed-off-by: Sébastien Han <seb@redhat.com>
If a specific disk is configured to have more than one OSD per device,
or if it has a metadata device specified, exclude it from raw mode on an
individual basis.
Signed-off-by: Blaine Gardner <blaine.gardner@redhat.com>
The osd destroy command leaves the osd id in use instead
of fully purging the osd id. If the osd id is not also
removed, it gives the impression that there is still
something that needs to be cleaned up from the old osd.
Signed-off-by: Travis Nielsen <tnielsen@redhat.com>
The purge job is intended to clean up all the resources
related to an OSD that is to be removed. An OSD with
a metadata, wal, and data PVC was only cleaning up the
data PVC. Now the metadata and wal PVCs will also be
cleaned up.
Signed-off-by: Travis Nielsen <tnielsen@redhat.com>
The OSD prepare job was succeeding even if the OSDs failed to be listed
by ceph-volume. These errors should be returned and fail the job, resulting
in a retry to retrieve the OSDs. Otherwise, the failure is masked and
the admin needs to dig through logs to find why the OSDs were not configured
on that node.
Signed-off-by: Travis Nielsen <tnielsen@redhat.com>