Skip to main content
For applications and automation, an engine administrator can manually create a dedicated SQLWorkspace engine user and grant only the privileges that the workload requires. The application then uses that engine identity to connect through the native PostgreSQL endpoint.

​
Create an engine user

The following example creates an engine user and grants read-only access to the managed sources in one schema:
Grant table, materialized-view, or write privileges only when the workload needs them. Do not grant SUPERUSER for routine application access. For supported privileges and commands, see Access control in RisingWave.

​
Use OAuth authentication

For token-based machine-to-machine authentication, RisingWave supports engine users configured with CREATE USER ... WITH oauth. The OAuth configuration identifies a JSON Web Key Set (JWKS) endpoint and issuer, and RisingWave validates the token header and claims when the client connects. You can use a StreamNative Cloud API key with this authentication flow. An engine administrator must first create an OAuth-authenticated engine user whose JWKS endpoint, issuer, and claim requirements match the API key. Creating a StreamNative Cloud service account does not automatically create this engine user. For the required configuration, token claims, audience validation, and SQL syntax, see Create a user with OAuth authentication in the RisingWave documentation.

​
Connect through the native endpoint

Configure the application with the SQLWorkspace native hostname, port 4567, target database, engine username, password or OAuth credential, and certificate-verifying TLS mode. For the complete connection fields, see Connect with a PostgreSQL Client.

​
Manage the identity lifecycle

Manually created engine users are not managed through StreamNative Cloud role bindings. You are responsible for:
  • Storing and rotating their passwords or OAuth credentials securely.
  • Reviewing and changing their engine privileges.
  • Revoking access or dropping the user when the workload no longer needs access.
Do not place a password or OAuth token in a connection URI, shell history, application log, or screenshot. Require TLS with certificate and hostname verification for native connections.