Bug 1992945

Summary: Vault config does not get updated during SC creation, if csi-kms-connection-details has custom KMS ID
Product: [Red Hat Storage] Red Hat OpenShift Data Foundation Reporter: Rachael <rgeorge>
Component: management-consoleAssignee: gowtham <gshanmug>
Status: CLOSED WONTFIX QA Contact: Elad <ebenahar>
Severity: high Docs Contact:
Priority: unspecified    
Version: 4.8CC: gshanmug, jefbrown, madam, ocs-bugs, odf-bz-bot, skatiyar
Target Milestone: ---Keywords: Reopened
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-08-27 09:22:35 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:
Attachments:
Description Flags
Screen recording of storageclass creation none

Description Rachael 2021-08-12 05:49:59 UTC
Created attachment 1813321 [details]
Screen recording of storageclass creation

Description of problem (please be detailed as possible and provide log
snippets):
During Storage class creation using RBD provisioner, the vault config or connection details can be modified in the storageclass creation page for encryption enabled SCs. 

However, when there is a custom KMS ID, for eg: "test-vault" instead of "1-vault", "2-vault" and so on, changing the vault connection details in the SC creation page does not get reflected in the UI and the newly created SC uses the old encryptionKMSID instead of the new one. 

The csi-kms-connection-details configmap gets updated, but the SC does not use the newly updated KMSID.

Version of all relevant components (if applicable):
OCP: 4.8.0-0.nightly-2021-08-09-135211
OCS: ocs-operator.v4.8.0

Does this issue impact your ability to continue to work with the product
(please explain in detail what is the user impact)?
Yes, since the newly created SC does not use the updated vault config

Is there any workaround available to the best of your knowledge?
Not that I am aware of. Editing the parameters of an SC is not allowed afaik.

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

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. Create an encryption enabled RBD storageclass and provide the vault config.
2. Under workloads -> configmap in the openshift-storage namespace, click on csi-kms-connection-details and go to the YAML tab. The output should look similar to this:

kind: ConfigMap
apiVersion: v1
metadata:
  name: csi-kms-connection-details
  namespace: openshift-storage
[...]
data:
  1-vault: >-
    {"KMS_PROVIDER":"vaulttokens","KMS_SERVICE_NAME":"vault","VAULT_ADDR":"https://vault.qe.rh-ocs.com:8200","VAULT_BACKEND_PATH":"rbd-encryption","VAULT_TLS_SERVER_NAME":"","VAULT_NAMESPACE":"ocs/rbd","VAULT_TOKEN_NAME":"ocs-kms-token","VAULT_CACERT_FILE":"","VAULT_CLIENT_CERT_FILE":"","VAULT_CLIENT_KEY_FILE":""}

3. Create another encryption enabled RBD SC and change the vault config in the SC creation page by clicking on "Change connection details" in the Connection details section

4. The csi-kms-connection-details configmap should now look like:

kind: ConfigMap
apiVersion: v1
metadata:
  name: csi-kms-connection-details
  namespace: openshift-storage
[...]
data:
  1-vault: >-
    {"KMS_PROVIDER":"vaulttokens","KMS_SERVICE_NAME":"vault","VAULT_ADDR":"https://vault.qe.rh-ocs.com:8200","VAULT_BACKEND_PATH":"rbd-encryption","VAULT_TLS_SERVER_NAME":"","VAULT_NAMESPACE":"ocs/rbd","VAULT_TOKEN_NAME":"ocs-kms-token","VAULT_CACERT_FILE":"","VAULT_CLIENT_CERT_FILE":"","VAULT_CLIENT_KEY_FILE":""}
  2-vault: >-
    {"KMS_PROVIDER":"vaulttokens","KMS_SERVICE_NAME":"vault","VAULT_ADDR":"https://vault.qe.rh-ocs.in:8201","VAULT_BACKEND_PATH":"rbd-encryption2","VAULT_TLS_SERVER_NAME":"","VAULT_NAMESPACE":"rbd-encryption","VAULT_TOKEN_NAME":"ocs-kms-token","VAULT_CACERT_FILE":"","VAULT_CLIENT_CERT_FILE":"","VAULT_CLIENT_KEY_FILE":""}
  
5. Edit the configmap above, by adding a new KMSID with a custom name under the data section as shown below and click on save

kind: ConfigMap
apiVersion: v1
metadata:
  name: csi-kms-connection-details
  namespace: openshift-storage
[...]
data:
  1-vault: >-
    {"KMS_PROVIDER":"vaulttokens","KMS_SERVICE_NAME":"vault","VAULT_ADDR":"https://vault.qe.rh-ocs.com:8200","VAULT_BACKEND_PATH":"rbd-encryption","VAULT_TLS_SERVER_NAME":"","VAULT_NAMESPACE":"ocs/rbd","VAULT_TOKEN_NAME":"ocs-kms-token","VAULT_CACERT_FILE":"","VAULT_CLIENT_CERT_FILE":"","VAULT_CLIENT_KEY_FILE":""}
  2-vault-2: >-
    {"KMS_PROVIDER":"vaulttokens","KMS_SERVICE_NAME":"vault-2","VAULT_ADDR":"https://vault.qe.rh-ocs.in:8201","VAULT_BACKEND_PATH":"rbd-encryption2","VAULT_TLS_SERVER_NAME":"","VAULT_NAMESPACE":"rbd-encryption","VAULT_TOKEN_NAME":"ocs-kms-token","VAULT_CACERT_FILE":"","VAULT_CLIENT_CERT_FILE":"","VAULT_CLIENT_KEY_FILE":""}
  test-vault: >-
    {"KMS_PROVIDER":"vaulttokens","KMS_SERVICE_NAME":"vault-3","VAULT_ADDR":"https://vault.qe.rh-ocs.in:8203","VAULT_BACKEND_PATH":"rbd","VAULT_TLS_SERVER_NAME":"","VAULT_NAMESPACE":"test-namespace","VAULT_TOKEN_NAME":"ocs-kms-token","VAULT_CACERT_FILE":"","VAULT_CLIENT_CERT_FILE":"","VAULT_CLIENT_KEY_FILE":""}

6. In the storageclass creation page, create a new encryption enabled RBD SC. In the Connection details section, edit the vault config by clicking on "Change connection details" and click on Save

7. Check if the connection details displayed is updated with the new values

Actual results:
The Connection details does not get updated with the new values. On creating the SC, it uses the old encryptionKMSID, even though the csi-kms-connection-details configmap has a new KMSID entry with the updated vault config.

kind: ConfigMap
apiVersion: v1
metadata:
  name: csi-kms-connection-details
  namespace: openshift-storage
[...]
data:
  1-vault: >-
    {"KMS_PROVIDER":"vaulttokens","KMS_SERVICE_NAME":"vault","VAULT_ADDR":"https://vault.qe.rh-ocs.com:8200","VAULT_BACKEND_PATH":"rbd-encryption","VAULT_TLS_SERVER_NAME":"","VAULT_NAMESPACE":"ocs/rbd","VAULT_TOKEN_NAME":"ocs-kms-token","VAULT_CACERT_FILE":"","VAULT_CLIENT_CERT_FILE":"","VAULT_CLIENT_KEY_FILE":""}
  2-vault-2: >-
    {"KMS_PROVIDER":"vaulttokens","KMS_SERVICE_NAME":"vault-2","VAULT_ADDR":"https://vault.qe.rh-ocs.in:8201","VAULT_BACKEND_PATH":"rbd-encryption2","VAULT_TLS_SERVER_NAME":"","VAULT_NAMESPACE":"rbd-encryption","VAULT_TOKEN_NAME":"ocs-kms-token","VAULT_CACERT_FILE":"","VAULT_CLIENT_CERT_FILE":"","VAULT_CLIENT_KEY_FILE":""}
  4-vault: >-
    {"KMS_PROVIDER":"vaulttokens","KMS_SERVICE_NAME":"vault","VAULT_ADDR":"https://vault.qe.rh-ocs.com:8200","VAULT_BACKEND_PATH":"kv-v2","VAULT_TLS_SERVER_NAME":"","VAULT_NAMESPACE":"kv-v2","VAULT_TOKEN_NAME":"ocs-kms-token","VAULT_CACERT_FILE":"","VAULT_CLIENT_CERT_FILE":"","VAULT_CLIENT_KEY_FILE":""}
  5-vault: >-
    {"KMS_PROVIDER":"vaulttokens","KMS_SERVICE_NAME":"vault","VAULT_ADDR":"https://vault.qe.rh-ocs.com:8200","VAULT_BACKEND_PATH":"kv-v2","VAULT_TLS_SERVER_NAME":"","VAULT_NAMESPACE":"kv-v2","VAULT_TOKEN_NAME":"ocs-kms-token","VAULT_CACERT_FILE":"","VAULT_CLIENT_CERT_FILE":"","VAULT_CLIENT_KEY_FILE":""}
  test-vault: >-
    {"KMS_PROVIDER":"vaulttokens","KMS_SERVICE_NAME":"vault-3","VAULT_ADDR":"https://vault.qe.rh-ocs.in:8203","VAULT_BACKEND_PATH":"rbd","VAULT_TLS_SERVER_NAME":"","VAULT_NAMESPACE":"test-namespace","VAULT_TOKEN_NAME":"ocs-kms-token","VAULT_CACERT_FILE":"","VAULT_CLIENT_CERT_FILE":"","VAULT_CLIENT_KEY_FILE":""}

$ oc get sc test-pv-encryption-3 -o yaml
allowVolumeExpansion: false
apiVersion: storage.k8s.io/v1
kind: StorageClass
[...]
parameters:
  clusterID: openshift-storage
  csi.storage.k8s.io/controller-expand-secret-name: rook-csi-rbd-provisioner
  csi.storage.k8s.io/controller-expand-secret-namespace: openshift-storage
  csi.storage.k8s.io/fstype: ext4
  csi.storage.k8s.io/node-stage-secret-name: rook-csi-rbd-node
  csi.storage.k8s.io/node-stage-secret-namespace: openshift-storage
  csi.storage.k8s.io/provisioner-secret-name: rook-csi-rbd-provisioner
  csi.storage.k8s.io/provisioner-secret-namespace: openshift-storage
  encrypted: "true"
  encryptionKMSID: test-vault
  imageFeatures: layering
  imageFormat: "2"
  pool: ocs-storagecluster-cephblockpool
provisioner: openshift-storage.rbd.csi.ceph.com
reclaimPolicy: Delete
volumeBindingMode: Immediate

Expected results:
The new SC should use the updated vault connection details (encryptionKMSID) that was provided during the SC creation

Additional info: Screen recording with the reproducer steps has been attached

Comment 3 Sanjal Katiyar 2021-08-16 15:33:03 UTC
Just FYI, from the UI side:
Some KMS related issues have been resolved for OCP 4.9 (https://bugzilla.redhat.com/show_bug.cgi?id=1969965 & https://bugzilla.redhat.com/show_bug.cgi?id=1969989). And this OCP 4.9 fix can solve this BZ(#1992945) as well (In case we are targeting this for OCP 4.9 ?)
Please refer https://github.com/openshift/console/pull/9409 to see the attached screenshots. We have added a dropdown now if there are multiple KMS connections.

For OCP 4.8 depending upon how things are implemented from the UI, if you will create a subsequent connection from the UI itself you will not face this issue, but, you are creating the subsequent connections patching the yaml directly this why it is happening (cause it is affecting the sorted order of the configMap we are polling, and for current 4.8 implementation we always pick the last element of the configMap).