# Passwordless Access to Neon DB with SSO

> Octelium documentation. Canonical page: <https://octelium.com/docs/octelium/latest/management/guide/service/databases/neon>.

Octelium provides seamless zero trust, secretless access to NeonDB or any SaaS PostgreSQL-based database (read more about `POSTGRES` *Services* [here](https://octelium.com/docs/octelium/latest/management/core/service/postgres.md)) without having to share and manage passwords (read more about secretless access [here](https://octelium.com/docs/octelium/latest/management/core/service/secretless.md)).

## A Simple Example

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

```bash
octeliumctl create secret neondb-password
```

Now we create a *Service* for our database as follows:

```yaml
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](https://octelium.com/docs/octelium/latest/management/core/overview.md)):

```bash
octeliumctl apply /PATH/TO/SERVICE.YAML
```

Now after connecting to the *Cluster* via the `octelium connect` command (read more about connecting to *Clusters* [here](https://octelium.com/docs/octelium/latest/user/cli/connect.md)), you can simply access the database whose hostname is at `neondb.default` or simply `neondb` (read more [here](https://octelium.com/docs/octelium/latest/management/core/service/overview.md#dns)) as follows:

```bash
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](https://octelium.com/docs/octelium/latest/management/core/service/dynamic-config.md). Here is an example where *Users* belonging to the `production` or `admins` *Groups* access a `production` database while the rest access a `development` database:

```yaml
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](https://octelium.com/docs/octelium/latest/management/core/service/postgres.md#access-control)

## Authentication

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

- GitHub OAuth *IdentityProvider* as shown in detail [here](https://octelium.com/docs/octelium/latest/management/core/identity-providers.md#github-oauth2)
- OpenID Connect *IdentityProviders* (e.g. Okta, Auth0, etc...) as shown [here](https://octelium.com/docs/octelium/latest/management/core/identity-providers.md#openid-connect).
- SAML 2.0 *IdentityProviders* (e.g. Okta, Entra ID, etc...) as shown [here](https://octelium.com/docs/octelium/latest/management/core/identity-providers.md#saml-20).

Furthermore, `HUMAN` *Users* can register their FIDO2 *Authenticators* (e.g. Yubikeys) in order to natively login later via Passkey (read more [here](https://octelium.com/docs/octelium/latest/management/core/authenticator.md#passkey-login)).

> **Note:**
>
> You can read more about *Authenticators* and WebAuthn/TOTP MFA as shown [here](https://octelium.com/docs/octelium/latest/management/core/authenticator.md).

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

- OAuth2 client credentials (read more [here](https://octelium.com/docs/octelium/latest/management/core/credential.md#oauth2-client-credentials))
- "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](https://octelium.com/docs/octelium/latest/management/core/identity-providers.md#oidc-assertion)).
- Access tokens directly issued and used as bearer authentication tokens (read more [here](https://octelium.com/docs/octelium/latest/management/core/credential.md#access-tokens)).

## Visibility

Octelium also provides OpenTelemetry-ready, application-layer L7 aware visibility and access logging in real time (see an example for PostgreSQL [here](https://octelium.com/docs/octelium/latest/management/core/service/postgres.md#visibility)). You can read more about visibility [here](https://octelium.com/docs/octelium/latest/management/core/visibility.md).