Passwordless Access to Neon DB with SSO

Octelium provides seamless zero trust, secretless access to NeonDB or any SaaS PostgreSQL-based database (read more about POSTGRES Services here) without having to share and manage passwords (read more about secretless access here).

A Simple Example

First we need to create a Secret for the database's password as follows:

octeliumctl create secret neondb-password

Now we create a Service for our database as follows:

kind: Service
metadata:
  name: neondb
spec:
  mode: POSTGRES
  config:
    upstream:
      url: postgres://ep-shiny-math-<123456>.eu-central-1.aws.neon.tech
    postgres:
      user: <USER>
      database: neondb
      auth:
        password:
          fromSecret: neondb-password
      sslMode: REQUIRE

You can now apply the creation of the Service as follows (read more here):

octeliumctl apply /PATH/TO/SERVICE.YAML

Now after connecting to the Cluster via the octelium connect command (read more about connecting to Clusters here), you can simply access the database whose hostname is at neondb.default or simply neondb (read more here) as follows:

psql -h neondb 

Dynamic Configuration

You can also provide dynamic secretless access where you can set different users, databases and passwords for different Users under different contexts. Read more about dynamic configuration here. Here is an example where Users belonging to the production or admins Groups access a production database while the rest access a development database:

apiVersion: core/v1
kind: Service
metadata:
  name: neondb
spec:
  mode: POSTGRES
  port: 5432
  dynamicConfig:
    configs:
      - name: production
        upstream:
          url: postgres://production-db.eu-central-1.aws.neon.tech
        postgres:
          user: prod-user
          database: prod-db
          auth:
            password:
              fromSecret: prod-password
          sslMode: REQUIRE
      - name: development
        upstream:
          url: postgres://development-db.eu-central-1.aws.neon.tech
        postgres:
          user: dev-user
          database: dev-db
          auth:
            password:
              fromSecret: dev-password
          sslMode: REQUIRE
    rules:
      - condition:
          match: ctx.user.spec.groups.hasAny(["production", "admins"])
        configName: production
      - condition:
          matchAny: true
        configName: development

note

You might also want to read about Octelium's PostgreSQL L7 aware access control here

Authentication

HUMAN Users can use their emails to authenticate to the Cluster via web browsers using IdentityProviders. There currently 3 methods:

GitHub OAuth IdentityProvider as shown in detail here
OpenID Connect IdentityProviders (e.g. Okta, Auth0, etc...) as shown here.
SAML 2.0 IdentityProviders (e.g. Okta, Entra ID, etc...) as shown here.

Furthermore, HUMAN Users can register their FIDO2 Authenticators (e.g. Yubikeys) in order to natively login later via Passkey (read more here).

note

You can read more about Authenticators and WebAuthn/TOTP MFA as shown here.

For WORKLOAD Users, they can authenticate themselves via the octelium login or octeliumctl login commands using various ways:

OAuth2 client credentials (read more here)
"Secretless" OpenID Connect identity assertions which can be used by octelium CLIs and containers running in cloud providers, GitHub Action runners, Kubernetes clusters, etc... (read more here).
Access tokens directly issued and used as bearer authentication tokens (read more here).

Visibility

Octelium also provides OpenTelemetry-ready, application-layer L7 aware visibility and access logging in real time (see an example for PostgreSQL here). You can read more about visibility here.