Cannot create administrator user when instance.api.enabled=true in on-prem environment

[smithmiro7-ui]

Based on my testing, it appears that when setting instance.api.enabled=true, there is no way to create an administrator user as can be done in the VM setup.

This occurs in an on-prem environment.

Issues observed

Calling the instance API status endpoint fails with an authorization error:

http:///ords/_/instance-api/stable/status

Response: Authorization failed.

Attempting to create a user via the ORDS CLI also fails:

ords config user add ords_dev "SQL Developer"

Expected behavior

There should be a supported way to create an administrator user when instance.api.enabled=true, similar to the process available in the VM environment.

Environment

Deployment type: On-prem

Configuration: instance.api.enabled=true

Question

Is there a recommended way to create the initial administrator user in this configuration?

[marcstef-oracle]

Thank you for your message.

We’re working on improving this area in the OrdsSrvs controller - specifically around probing pools, and we’re also evaluating deeper use of the ORDS instance API.

One option we’re considering is supporting a user‑provided Kubernetes Secret that contains an administrator username/password (or just the password) that the operator could use to set up the initial administrator user.

Would providing a Secret with an administrator password be viable in your environment (from a security/compliance and operational perspective)?

[smithmiro7-ui]

Hi @marcstef-oracle ,
From our organization’s perspective, providing a Kubernetes Secret with an administrator password could be a viable approach, provided it aligns with our internal security and compliance policies.
Thank you.

[marcstef-oracle]

A beta implementation is available in the ordssrvs_development branch. In this version, it is possible to provide a Kubernetes Secret with the administrator credentials, which the operator uses to bootstrap the Instance API user.

You are welcome to test it and share your feedback.

[vova123412]

Hi @marcstef-oracle ,

Thank you very much for your excellent work.

I encountered several challenges while trying to run the solution locally and within our private network. Specifically, the configuration in oracle-database-operator.yaml did not work, as it appears to contain outdated CRDs. In addition, when attempting to run make run, I encountered multiple go vet errors (although go run ./main worked correctly after generating certificates or setting ENABLE_WEBHOOKS=false).

I also experienced an issue with an older Podman version (3.4.4), which resulted in an invalid mount type "cache" error. After resolving this, I generated the CRDs, transferred them into our private environment, and successfully ran the version. While I understand that this setup is intended to run in a clean environment, we would like to ensure that all functionality operates correctly in our environment as well.

Following an upgrade from a previous version, the operator did not update the ConfigMaps (ords_init.sh remained unchanged). Consequently, the metrics did not function correctly. After recreating the ordssrv resource, ORDS started successfully.

We conducted pressure tests without upgrading ORDS, and the results appeared stable. However, we encountered some issues after the upgrade, which we suspect may be environment-related. I will provide an update after further testing. We also plan to test all endpoints, although I understand this may not be directly related.

It would be highly beneficial to have comprehensive documentation outlining all prerequisites and detailed instructions for running the solution. I will open a separate issue to address this topic.

[marcstef-oracle]

Thanks for testing this beta version.

It is still not clear whether you were able to enable and use the Instance API successfully.
Please confirm whether the bootstrap worked, the admin user was created, and the Instance API was usable.

The operator setup and environment issues should be tracked separately.

[vova123412]

@marcstef-oracle Thank you for following up.

The feature was successfully tested and enabled. The bootstrap process completed as expected, the administrative user was created, and the Instance API is operational and usable.

[marcstef-oracle]

Thanks for testing.
We’ll keep this issue open until it is included in an official release, hopefully v2.2.

[marcstef-oracle]

The feature will be included in version 2.2.