SIDB: problem with TCPS support
ilfur opened this issue · 0 comments
Hello fellow OraOperator's :-)
I like the feature that a SIDB can be published through SSL ports.
Curently, OraOperator handles the creation and refreshing of certificates.
This is done by OraOperator which creates a self-signed certificate as the root CA, then creating a certificate to be put in the DB wallet.
This gives a problem:
Only C-written programs like sqlcl , sqlplus would tolerate a self-signed root CA certificate, all Java Clients and most other languages would complain about an invalid or missing root CA. Customers would be forced to add this self-signed root CA certificate to their JDKs trust-path or so.
This gives another problem:
Customers would not be able to use their own official root CA certificates for clean certificate creation.
This also gives a disadvantage:
Its feasible to copy out the database certificate and the whole wallet through "kubectl cp" commands, a more kubernetes-conforming way would be to pack the database client wallet inside a kubernetes secret instead.
Suggestion on solution:
Do not let OraOperator handle Certificates for DB wallets. OraOperator already uses cert-manager for a ValidatingWebHook, why not also use it for creating/refreshing certificates once the customer has also supplied an official rootCA certificate to cert-manager ?
OraOperator could check if there is a new / refreshed certificate available (most often a kubernetes secret of certificate type) and create a DB wallet from it.
OraOperator could also create/refresh the DB client wallet into a kubernetes secret, which could then be easily used in client deployments just by mounting them.
What do You think? Feasible, meaningful, other plans ?