Bug 1915202 - Can not configure KMS with unknown CA certificate
Summary: Can not configure KMS with unknown CA certificate
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat OpenShift Container Storage
Classification: Red Hat Storage
Component: management-console
Version: 4.7
Hardware: Unspecified
OS: Unspecified
unspecified
high
Target Milestone: ---
: ---
Assignee: gowtham
QA Contact: Elad
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2021-01-12 09:08 UTC by Shay Rozen
Modified: 2023-09-15 00:58 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2021-01-18 12:40:48 UTC
Embargoed:


Attachments (Terms of Use)

Description Shay Rozen 2021-01-12 09:08:43 UTC
Description of problem (please be detailed as possible and provide log
snippests):
There isn't an option to configure one of KMS values VAULT_SKIP_VERIFY via UI hence can't test with unknown CA certificate. Via yaml the option is configurable.



Version of all relevant components (if applicable):
All ocp4.7 ocs4.7


Does this issue impact your ability to continue to work with the product
(please explain in detail what is the user impact)?
Can test KMS without certificates signed by trusted CA


Is there any workaround available to the best of your knowledge?
Work with trusted CA


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?
Yes

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

Steps to Reproduce:
1. Install OCP4.7
2. Configure KMS
3. Install ocs-operator
4. Add storage cluster with encryption and KMS


Actual results:
OCS will install and the following error occur:
ceph-cluster-controller: failed to reconcile. failed to reconcile cluster "ocs-storagecluster-cephcluster": failed to configure local ceph cluster: failed to create cluster: failed to start ceph osds: 3 failures encountered while running osds in namespace openshift-storage: failed to store secret. failed to init vault kms: failed to initialize vault secret store: Get "https://vault.default.svc.cluster.local:8200/v1/sys/mounts": x509: certificate signed by unknown authority


Expected results:
Have the option to configure VAULT_SKIP_VERIFY as installing via cli.


Additional info:

Comment 3 gowtham 2021-01-12 17:04:25 UTC
Hi @

Comment 4 gowtham 2021-01-12 17:16:32 UTC
 My understanding is after enabling encryption with TLS, Supporting an unknown CA certificate will lead to an insecure connection. Also, if we don't want a secure connection then we can disable TLS in the vault. Does this option make sense at the product level? Please connect me if I am wrong.

Need info @

Comment 5 gowtham 2021-01-13 14:03:27 UTC
Hi,
  I have discussed this issue with Eran and he suggested adding this key-value manually to the config map (rook restart may be required, will confirm that) and document these steps. We have to figure out how important this fix for the customers and it is happening commonly or not, Based on that we will fix this bug in a later release. 

Any thoughts?

Comment 6 Shay Rozen 2021-01-13 19:55:29 UTC
I don't understand why we can't make it simple to the customer to have this option when he will do a POC or other DEV environment that will not have to use trusted certificate. I think @sebastien han and I agree that it will broadly used.

Comment 7 gowtham 2021-01-15 06:36:09 UTC
Hi,
  Just need to clarify one thing, 
    If the product allows the customer to use a trusted and non-trusted certificate do we really need to ask for this option? What if the customer enables this option and uploads trusted certificates. I don't see UI is the right place to fix this issue.

My suggestion is:
  Either rook or OCS operator can validate the certificates and decide whether to add this option or not.

Comment 15 Red Hat Bugzilla 2023-09-15 00:58:11 UTC
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 500 days


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