Skip to content

SIDB: problem with TCPS support #81

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
ilfur opened this issue Jan 23, 2024 · 0 comments
Open

SIDB: problem with TCPS support #81

ilfur opened this issue Jan 23, 2024 · 0 comments
Assignees

Comments

@ilfur
Copy link

ilfur commented Jan 23, 2024

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 ?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants