Bug 1944980 - Noobaa deployment fails when no KMS backend path is provided during storagecluster creation
Summary: Noobaa deployment fails when no KMS backend path is provided during storagecl...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat OpenShift Container Storage
Classification: Red Hat Storage
Component: Multi-Cloud Object Gateway
Version: 4.7
Hardware: Unspecified
OS: Unspecified
unspecified
high
Target Milestone: ---
: OCS 4.7.0
Assignee: Nimrod Becker
QA Contact: Rachael
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2021-03-31 06:41 UTC by Rachael
Modified: 2021-06-01 08:47 UTC (History)
8 users (show)

Fixed In Version: 4.7.0-336.ci
Doc Type: No Doc Update
Doc Text:
Clone Of:
Environment:
Last Closed: 2021-05-19 09:20:51 UTC
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github noobaa noobaa-operator pull 595 0 None closed Fix for vault kms - when missing backend path field will use the default (secret/) 2021-03-31 11:47:03 UTC
Github noobaa noobaa-operator pull 597 0 None closed Backport to 5.7: fix kms - missing backend path field 2021-03-31 11:47:03 UTC
Red Hat Product Errata RHSA-2021:2041 0 None None None 2021-05-19 09:21:36 UTC

Description Rachael 2021-03-31 06:41:30 UTC
Description of problem (please be detailed as possible and provide log
snippets):

When no backend path is specified while deploying an OCS cluster with cluster wide encryption enabled using KMS, the noobaa pods do not get created. The following messages are seen in the noobaa-operator logs:

time="2021-03-31T06:19:27Z" level=warning msg="⏳ Temporary Error: got error in fetch root secret from external KMS Error making API request.\n\nURL: GET https://vault.qe.rh-ocs.com:8200/v1/NOOBAA_ROOT_SECRET_PATH/rootkeyb64-d650f092-a5ce-413e-83f2-47dd8597ac93\nCode: 403. Errors:\n\n* 1 error occurred:\n\t* permission denied\n\n" sys=openshift-storage/noobaa

This issue was hit, while verifying the fix for https://bugzilla.redhat.com/show_bug.cgi?id=1941647
Rook sets the backend path to "secret" if no backend path is provided during storagecluster creation. However, in ocs-kms-connection-details configmap, the value for backend path is left blank. This might have caused the error seen above

$ oc get cm ocs-kms-connection-details -o yaml
apiVersion: v1
data:
  KMS_PROVIDER: vault
  KMS_SERVICE_NAME: vault
  VAULT_ADDR: https://vault.qe.rh-ocs.com:8200
  VAULT_BACKEND_PATH: ""
  VAULT_CACERT: ocs-kms-ca-secret-i8h7w59
  VAULT_CLIENT_CERT: ocs-kms-client-cert-itwn5b
  VAULT_CLIENT_KEY: ocs-kms-client-key-tckf9o
  VAULT_NAMESPACE: ""
  VAULT_TLS_SERVER_NAME: vault.qe.rh-ocs.com
kind: ConfigMap


Version of all relevant components (if applicable):
OCP: 4.7.0-0.nightly-2021-03-30-235343
OCS: ocs-operator.v4.7.0-324.ci


Does this issue impact your ability to continue to work with the product
(please explain in detail what is the user impact)?
Yes, Noobaa does not get deployed successfully.

Is there any workaround available to the best of your knowledge?
Editing the ocs-kms-connection-details and setting VAULT_BACKEND_PATH to "secret" resolves the issue.

Rate from 1 - 5 the complexity of the scenario you performed that caused this
bug (1 - very simple, 5 - very complex)?
3

Can this issue reproducible?
Yes

Can this issue reproduce from the UI?
Yes

If this is a regression, please provide more details to justify this:
No

Steps to Reproduce:
1. On the vault server, ensure that you have a path called secret/
2. Deploy an OCS cluster with cluster wide encryption enabled using KMS, in the Advanced settings section, do not specify the backend path
3. Check the status of the storagecluster


Actual results:
The noobaa related pods are not created if no backend path for KMS is specified

Expected results:
Since the backend path value is not a mandatory value during storagecluster creation when encryption with KMS is enabled, the deployment of Noobaa should be successful even if no value is provided for the same.

Comment 8 errata-xmlrpc 2021-05-19 09:20:51 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (Moderate: Red Hat OpenShift Container Storage 4.7.0 security, bug fix, and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2021:2041


Note You need to log in before you can comment on or make changes to this bug.