Let users sign in to RisingWave Console through your SAML, LDAP / Active Directory, or OIDC identity provider using the bundled Dex identity broker.
RisingWave Console can federate console sign-in to your identity provider (IdP) so users authenticate with their existing corporate credentials instead of a local Console password.SSO is powered by a Dex identity broker that runs alongside Console — a sidecar container on Kubernetes, or a second service on Docker Compose. You enable it by deploying Console together with Dex, then register one or more connectors (SAML, LDAP / Active Directory, or OIDC) from the Console UI.
Console runs a Dex identity broker next to it and wires itself to Dex. The design avoids the usual SSO operational burden:
No separate Dex endpoint. Console reverse-proxies Dex under its own /dex path, so whatever exposes Console also serves Dex. You publish only the Console port — no separate Dex Service, Ingress path, or published port.
No operator-managed client secret. Console self-registers its OIDC client with Dex at boot and generates the client secret itself.
No certificate wrangling for users. Console reaches Dex’s gRPC admin port over the loopback (Docker network or pod loopback), secured by a self-signed certificate you generate once (Docker) or that an init container mints per pod (Kubernetes).
No forwarded-header configuration. Console derives both the OAuth redirect URI and the SSO state cookie’s Secure flag from the configured issuer URL, so SSO works correctly behind a TLS-terminating proxy without trusting X-Forwarded-* headers.
Connectors you add from the UI are pushed to Dex immediately over its admin API — no Dex or Console restart is required.
A signed RisingWave license key. Console v0.7.x performs startup license verification and exits without RW_LICENSE_KEY / RW_LICENSE_KEY_PATH. See Manage license keys.
A stable host for the issuer. Set the Dex issuer to <scheme>://<host>/dex, where <host> is exactly the host (and port) browsers use to reach Console. Because Console serves Dex under its own /dex path, the issuer host must equal the Console host. Use HTTPS in production; the cookie Secure flag follows the issuer scheme.
A single Console instance. The self-register flow resets the OIDC client secret on every boot, so run exactly one replica. The Kubernetes manifest pins replicas: 1; the Docker Compose setup is single-instance by nature.
This brings up Console (with bundled PostgreSQL) and a Dex container on one host. Only the Console port is published; Dex stays on the internal Compose network and is reached through Console’s /dex proxy.You need Docker with Compose v2, OpenSSL, and a signed RisingWave license token.
3. Generate a certificate for Dex’s gRPC admin port
Console talks to Dex’s admin port over TLS. Generate a self-signed certificate whose subject alternative name is dex (the Compose service name Console connects to):
The files above are ready to run for local evaluation at http://localhost:8020. Before exposing Console to other machines:
Replace localhost:8020 with the host and port browsers will use, in both the issuer: in dex-config.yaml and RCONSOLE_SSO_DEX_ISSUERURL in docker-compose.yaml (they must be byte-identical). For production, front Console with a TLS proxy and use an https:// issuer.
The dex-init service chowns the Dex data volume so the non-root Dex can write its SQLite store (the Compose equivalent of Kubernetes fsGroup). Console waits for Dex to become healthy (depends_on), so it self-registers its OIDC client cleanly on the first boot.
Open http://localhost:8020 and sign in as root with the password from RCONSOLE_ROOT_PASSWORD (it defaults to root only if you leave that variable unset).
On Kubernetes, Dex runs as a sidecar container in the Console pod. The manifest below is the bundled-PostgreSQL (“pgbundle”) variant — convenient for testing, but its PostgreSQL metadata is not durable across pod rescheduling. For production, use an external PostgreSQL deployment and add the same Dex sidecar; see Install RisingWave Console for the external-PostgreSQL base.
Dex’s own state (signing keys, registered connectors) is stored in SQLite on
the pod’s PVC and survives restarts. With the bundled-PostgreSQL image, the
Console metadata is not on the PVC, so use external PostgreSQL for production.
Save the following as risingwave-console-sso.yaml. It creates the namespace, service account, RBAC, license Secret, Dex ConfigMap, a NodePort Service, and a single-replica StatefulSet whose pod runs the Console container, the Dex sidecar, and an init container that mints the per-pod gRPC certificate.
License: replace license.jwt: <your-signed-license-token> in the risingwave-console-license Secret.
Issuer host: replace console.example.com with your Console’s external host in both places (they must be byte-identical):
issuer: in the risingwave-console-dexConfigMap
RCONSOLE_SSO_DEX_ISSUERURL in the StatefulSet
Root password (optional): the default login is root / root. To change it, add a RCONSOLE_ROOT_PASSWORD env var to the console container.
replicas: 1 is load-bearing. The self-register flow resets the Dex OIDC
client secret on every boot; with more than one replica each pod would
overwrite the others’ secret, causing random 401s on SSO login.
The manifest exposes Console on NodePort 30020. Add an Ingress (or other TLS-terminating front end) that serves Console at your issuer host over HTTPS. No forwarded-header trust configuration is needed.
kubectl apply -f risingwave-console-sso.yamlkubectl -n risingwave-console get pod risingwave-console-0 # READY should reach 2/2kubectl -n risingwave-console logs risingwave-console-0 -c console | grep -i "SSO self-register"# Expected: SSO self-registered OIDC client "risingwave-console" with Dex
On the very first boot, the console can start before the Dex sidecar’s
gRPC port is ready and log SSO Dex unreachable followed by
SSO login disabled this boot. The console does not retry self-registration
within that boot, so SSO login stays disabled until the next restart. If you
see this, restart the console once Dex is up:
Both deployment methods set the RCONSOLE_SSO_DEX_* variables for you. You normally edit only the issuer host. The full set is documented here for custom deployments.
Environment variable
Description
RCONSOLE_SSO_DEX_GRPCADDR
Dex gRPC admin endpoint Console connects to, for example dex:5557 (Docker) or localhost:5557 (Kubernetes pod loopback).
RCONSOLE_SSO_DEX_CACERT
Path to the PEM CA certificate Console uses to verify Dex’s gRPC server certificate.
RCONSOLE_SSO_DEX_CLIENTCERT
(Optional) Client certificate for mTLS to Dex’s gRPC admin port. Must be set together with RCONSOLE_SSO_DEX_CLIENTKEY.
RCONSOLE_SSO_DEX_CLIENTKEY
(Optional) Private key for the client certificate above.
RCONSOLE_SSO_DEX_ISSUERURL
Browser-facing OIDC issuer URL, for example https://console.example.com/dex. Must match the issuer in the Dex config exactly.
RCONSOLE_SSO_DEX_CLIENTID
OIDC client id Console registers as in Dex. Use risingwave-console.
RCONSOLE_SSO_DEX_CLIENTSECRET
OIDC client secret. Leave unset when RCONSOLE_SSO_DEX_SELFREGISTERCLIENT is true (Console generates and owns the secret).
RCONSOLE_SSO_DEX_INTERNALISSUERURL
Back-channel Dex URL Console uses for token exchange and JWKS, for example http://dex:5556/dex. The iss claim still uses the external issuer.
RCONSOLE_SSO_DEX_SELFREGISTERCLIENT
When true, Console generates its own OIDC client secret at boot and registers itself with Dex. Requires ISSUERURL and CLIENTID, and that CLIENTSECRET be unset.
RCONSOLE_SSO_DEX_SERVEOIDCPROXY
When true, Console reverse-proxies Dex’s HTTP surface under its own /dex path. Requires RCONSOLE_SSO_DEX_INTERNALISSUERURL.
After Console is running, sign in as root and add a connector for your IdP. Connectors are pushed to Dex immediately; no restart is needed.
In the sidebar, open SSO Connectors.Before you add anything, the page shows an empty state.
Click Add connector and fill in the form:
Connector id: a stable identifier, for example okta-prod. This is used internally and cannot be changed later.
Type: SAML 2.0, LDAP / Active Directory, or OIDC.
Display name: the label shown on the sign-in button, for example Okta (Production).
Configuration (JSON): connector-specific settings passed to Dex. Selecting a type pre-fills a template with the keys that connector expects; fill in the values.
Click Create connector.
Each configured connector appears in the list, where you can edit or delete it.
The configuration field holds connector-specific JSON that Dex validates on save. Selecting a type pre-fills the keys that connector expects.For connectors that verify an IdP or directory server certificate, use the Load CA certificate button to fill the inline CA field from a PEM file. Console uses Dex’s inline CA form (caData for SAML, rootCAData for LDAP) rather than a filesystem path, because a path would point inside the Dex container.
Use Load CA certificate to fill caData with the base64-encoded PEM of the IdP’s signing CA. SAML requires it unless signature validation is disabled (dev and test only).
Use Load CA certificate to fill rootCAData with the base64-encoded PEM of the LDAPS server’s CA. Leave it empty for plain LDAP or when the server certificate chains to a publicly trusted root.
Once SSO is enabled — Console is deployed alongside Dex, Dex is reachable, and Console has registered its OIDC client — the login page shows a Sign in with SSO button alongside the local username and password fields. Users click it to authenticate through your IdP.Register at least one IdP connector before pointing users at SSO, so the button leads to a real identity provider rather than only Dex’s built-in local login.
The local root account and any local users you create continue to work, so you retain an administrative path even if the IdP is unavailable.
Check the console log for SSO login disabled this boot (first-boot race with the Dex sidecar) and restart the console. Otherwise confirm Dex is reachable and the OIDC issuer/client fields (or self-register mode) are set.
SSO login disabled this boot in the console log
The console started before Dex’s gRPC port was ready and did not retry. On Kubernetes, restart: kubectl -n risingwave-console rollout restart statefulset/risingwave-console. The Docker Compose setup avoids this with depends_on.
Unregistered redirect_uri on SSO login
The issuer host must equal the host browsers use to reach Console. Make RCONSOLE_SSO_DEX_ISSUERURL and the Dex issuer byte-identical to that host.
Dex container exits with permission denied on its key or DB
Dex runs as a non-root user. Ensure the gRPC cert/key are readable (chmod 644) and the Dex data volume is writable (the dex-init service handles this on Docker; fsGroup handles it on Kubernetes).
Random 401 errors on SSO login
The deployment is running more than one replica. The self-register flow requires a single instance.
Login fails with a certificate or signature error
Confirm the inline CA (caData / rootCAData) matches the IdP or LDAPS server certificate. Use Load CA certificate to set it from the PEM file.
Console exits at boot with an SSO configuration error
The OIDC fields are all-or-nothing. In self-register mode set ISSUERURL and CLIENTID and leave CLIENTSECRET unset; in hand-configured mode set issuer, client id, and client secret together.