Bug 1991805

Summary: [RFE] [KMS] Add input validation for VAULT_BACKEND parameter in RBD PV encryption
Product: [Red Hat Storage] Red Hat OpenShift Data Foundation Reporter: Rachael <rgeorge>
Component: unclassifiedAssignee: Mudit Agarwal <muagarwa>
Status: CLOSED WONTFIX QA Contact: Raz Tamir <ratamir>
Severity: high Docs Contact:
Priority: unspecified    
Version: 4.7CC: bniver, ebenahar, etamir, gmeno, muagarwa, ocs-bugs, odf-bz-bot, sostapov, tmuthami
Target Milestone: ---Keywords: FutureFeature
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2021-10-04 06:03:20 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Rachael 2021-08-10 04:57:25 UTC
Description of problem (please be detailed as possible and provide log
snippets):

The VAULT_BACKEND parameter introduced for RBD PV encryption as part of https://bugzilla.redhat.com/show_bug.cgi?id=1983931 does not have any input validation for the values passed to the parameter. There are only two valid values for the parameter "kv" and "kv-v2". But, it accepts any other random values for the parameter and does not throw an error or raise a warning. 

       3-vault: '{"KMS_PROVIDER":"vaulttokens","KMS_SERVICE_NAME":"vault","VAULT_ADDR":"https://vault.qe.rh-ocs.com:8200","VAULT_BACKEND_PATH":"bug1","VAULT_CACERT":"ocs-kms-ca-secret- 
       o1icyg","VAULT_TLS_SERVER_NAME":"","VAULT_CLIENT_CERT":"ocs-kms-client-cert-h0z11d","VAULT_CLIENT_KEY":"ocs-kms-client-key-hgy4x","VAULT_NAMESPACE":"","VAULT_TOKEN_NAME":"ocs-kms- 
       token","VAULT_CACERT_FILE":"fullchain.pem","VAULT_CLIENT_CERT_FILE":"cert.pem","VAULT_CLIENT_KEY_FILE":"privkey.pem","VAULT_BACKEND":"test-123!"}'
       4-vault: '{"KMS_PROVIDER":"vaulttokens","KMS_SERVICE_NAME":"vault","VAULT_ADDR":"https://vault.qe.rh-ocs.com:8200","VAULT_BACKEND_PATH":"bug","VAULT_CACERT":"ocs-kms-ca-secret- 
       35i1ma","VAULT_TLS_SERVER_NAME":"","VAULT_CLIENT_CERT":"ocs-kms-client-cert-ja7ani","VAULT_CLIENT_KEY":"ocs-kms-client-key-jrtckg","VAULT_NAMESPACE":"","VAULT_TOKEN_NAME":"ocs-kms- 
       token","VAULT_CACERT_FILE":"fullchain.pem","VAULT_CLIENT_CERT_FILE":"cert.pem","VAULT_CLIENT_KEY_FILE":"privkey.pem","VAULT_BACKEND":"123-test@"}'

   PVC and pod creation succeeded and the encryption keys were created in the respective backend paths.

Version of all relevant components (if applicable):
OCS: ocs-operator.v4.7.3-243.ci


Does this issue impact your ability to continue to work with the product
(please explain in detail what is the user impact)?
No

Is there any workaround available to the best of your knowledge?
Not that I am aware of

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

Can this issue reproducible?
Yes

Can this issue reproduce from the UI?
No

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

Steps to Reproduce:
1. Create a storage class with encryption enabled using the steps here : https://access.redhat.com/documentation/en-us/red_hat_openshift_container_storage/4.7/html-single/managing_and_allocating_storage_resources/index#creating-a-storage-class-for-persistent-volume-encryption_rhocs
2. Find out the encryptionKMSID being used for the storageclass
   $ oc get sc <sc_name> -o yaml |grep encryptionKMSID
   encryptionKMSID=4-vault
3. Edit the vault config for the KMSID from the step above in the csi-kms-connection-details configmap
   $ oc edit cm csi-kms-connection-details -n openshift-storage
4. Add the VAULT_BACKEND parameter to the vault config with an invalid value, as shown below
       4-vault: '{"KMS_PROVIDER":"vaulttokens","KMS_SERVICE_NAME":"vault","VAULT_ADDR":"https://vault.qe.rh-ocs.com:8200","VAULT_BACKEND_PATH":"bug","VAULT_CACERT":"ocs-kms-ca-secret- 
       35i1ma","VAULT_TLS_SERVER_NAME":"","VAULT_CLIENT_CERT":"ocs-kms-client-cert-ja7ani","VAULT_CLIENT_KEY":"ocs-kms-client-key-jrtckg","VAULT_NAMESPACE":"","VAULT_TOKEN_NAME":"ocs-kms- 
       token","VAULT_CACERT_FILE":"fullchain.pem","VAULT_CLIENT_CERT_FILE":"cert.pem","VAULT_CLIENT_KEY_FILE":"privkey.pem","VAULT_BACKEND":"123-test@"}'
5. Save the configmap
6. Create a PVC using the SC and attach it to a pod
7. Check the status of the PVC and Pod

Actual results:
PVC and pod creation is successful. The key is generated for the corresponding PV in Vault

Expected results:
Editing of configmap with invalid values should not be allowed.

Comment 3 Mudit Agarwal 2021-09-20 11:30:16 UTC
Keeping it for 4.9.0 as of now, if we decide to backport we can create the clones.

Comment 4 Mudit Agarwal 2021-09-22 14:51:38 UTC
Eran,
From engineering side, we don't see a good way to fix this until this feature is available via UI (where UI validations can be done)
Should we keep this BZ open, are there any plans for UI?

Comment 6 Mudit Agarwal 2021-09-27 10:58:59 UTC
No plans to fix this as of now.