Created attachment 1858014 [details] Authentication path/namespace fields missing Description of problem (please be detailed as possible and provide log snippets): In ODF 4.10, when cluster-wide encryption is enabled using KMS with kubernetes auth method, there is no field to specify custom authentication path and authentication namespace used in Vault while configuring the kubernetes authentication method. These options are available storageclass encryption is enabled during deployment. The same fields should be available for cluster wide encryption with kubernetes auth method as well. Version of all relevant components (if applicable): --------------------------------------------------- OCP: 4.10.0-0.nightly-2022-01-30-073053 ODF: odf-operator.v4.10.0 full_version=4.10.0-122 Does this issue impact your ability to continue to work with the product (please explain in detail what is the user impact)? Yes, if the user configures a non-default auth path or namespace for kubernetes authentication method in Vault, there is no way specifying these details via UI during deployment. Is there any workaround available to the best of your knowledge? The ocs-kms-connection-details can be edited via CLI after the storagesystem creation process starts to add the auth path and/or namespace 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. Install the ODF Operator 2. Create a storagesystem 3. On the Security and network page, enable cluster-wide encryption and select "Connect to an external key management service" 4. Set the authentication method as Kubernetes 5. Click on Advanced settings Actual results: --------------- There is no field to specify authentication path and authentication namespace if the user decides to configure kube auth method at a non-default path and/or within a namespace in Vault Expected results: ----------------- Text fields to specify auth path and namespace should be present
Why do we need to expose every bit of the YAML functionality in the UI?
For the use case where kubernetes authentication method is enabled at any other path in Vault other than "kubernetes", we would need to specify the path explicitly in the ocs-kms-connection-details configmap for the deployment to succeed. If we don't have the option of specifying this in the UI, the workaround would be to start the storagesystem creation from the UI (which would fail because the authentication config is not available at the default path in Vault) and then go and edit the configmap manually to add this parameter to trigger another reconcile loop for the deployment to eventually succeed. I am not sure how often such a use case is deployed but I don't think this is a good user experience for a GA'd feature. With adding just two more fields in the UI we reduce a lot of manual steps in between.
vaultAuthPath and vaultAuthNamespace are Ceph-CSI specific, This option is available only when storage class encryption is enabled. cluster-wide encryption is rook specific and rook does not want this.
Hi Gowtham, Yes VAULT_AUTH_MOUNT_PATH is supported in 4.10. We could expose it as an optional field. I thought the optional fields could accept any value? Isn't that the case? Do we have to map 1:1 each time we want to expose an optional field?
Yes, it is a 1:1 map in UI, Under KMS advanced settings screen each optional field is collected with specific input components. so the user has to enter it specifically and it is passed to "ocs-kms-connection-details" configMap
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 (Important: OpenShift Container Platform 4.11.0 bug fix and security 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-2022:5069