Bug 2051878
| Summary: | [KMS] PVC creation succeeds even if no TLS certs are provided for Vault in the kms connection details | ||
|---|---|---|---|
| Product: | [Red Hat Storage] Red Hat OpenShift Data Foundation | Reporter: | Rachael <rgeorge> |
| Component: | csi-driver | Assignee: | Niels de Vos <ndevos> |
| Status: | CLOSED NOTABUG | QA Contact: | Elad <ebenahar> |
| Severity: | high | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 4.10 | CC: | madam, ndevos, ocs-bugs, odf-bz-bot |
| Target Milestone: | --- | ||
| 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: | 2022-02-08 14:28:26 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: | |||
Providing the CA certificate is only needed when the CA that signed the certificate on the service is not trusted by default. As you are using https://vault-cluster.vault.2467e33a-73f9-408b-b9ff-b0476a654d30.aws.hashicorp.cloud:8200 as a service, the CA is already trusted, and no corporate-internal certificates need to be specified. When connecting to the service with curl, I do not get an error or warning about the certificate, indicating my system (Fedora 35) accepts the CA without any manual actions needed: $ curl 'https://vault-cluster.vault.2467e33a-73f9-408b-b9ff-b0476a654d30.aws.hashicorp.cloud:8200' (No need for curls `--insecure` option) I think everything works as expected? |
Description of problem (please be detailed as possible and provide log snippets): When no TLS certificates are provided during the creation of the kms connection details in the csi-kms-connection-details, the PVC creation still succeeds. It appears that the default behavior is to skip the CA verification. $oc get cm csi-kms-connection-details -o yaml [...] vault-token: '{"encryptionKMSType":"vaulttokens","kmsServiceName":"vault-token","vaultAddress":"https://vault-cluster.vault.2467e33a-73f9-408b-b9ff-b0476a654d30.aws.hashicorp.cloud:8200","vaultBackendPath":"rook","vaultTLSServerName":"","vaultNamespace":"admin","vaultCAFileName":"","vaultClientCertFileName":"","vaultClientCertKeyFileName":"","vaultAuthMethod":"token","tenantTokenName":"ceph-csi-kms-token"}' $ oc get sc test-pv-encryption-1 -o yaml |grep encrypt name: test-pv-encryption-1 encrypted: "true" encryptionKMSID: vault-token $ oc get pvc -n test NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE rbd-1 Bound pvc-0d487c5f-d460-4433-8754-e5efcb75324d 10Gi RWO test-pv-encryption-1 97m Version of all relevant components (if applicable): OCP: 4.10.0-0.nightly-2022-02-07-162517 ODF: odf-operator.v4.10.0 full_version=4.10.0-146 Does this issue impact your ability to continue to work with the product (please explain in detail what is the user impact)? Is there any workaround available to the best of your knowledge? The workaround would be to enforce CA certificate verification by setting the following in the kms connection details: "vaultCAVerify":"true" 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: Steps to Reproduce: ------------------- 1. Create an encryption enabled RBD storageclass. While creating the new KMS connection, do not specify the certificates. 2. Create a PVC using the storageclass created above. 3. Check status of the PVC Actual results: --------------- PVC is in bound state Expected results: ----------------- PVC provisioning should fail in the absence of valid TLS certificates, unless vaultCAVerify is explicity set to False. Additional info: ---------------- This behavior was observed for both vaulttokens and vaulttenantsa KMSTypes.