You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 ?
The text was updated successfully, but these errors were encountered:
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 ?
The text was updated successfully, but these errors were encountered: