Identity Providers

Lakehousecat supports OAuth/OIDC-based Single Sign-On as an optional authentication layer. When configured, users can sign in using their existing organizational credentials instead of (or in addition to) a native email/password account.

Operator Configuration

Identity provider integration is configured at the Operator level in the Lakehousecat CR YAML — not through the application UI. Configuration changes require access to the Kubernetes cluster.

Supported Providers

Provider	Key
Google	google
Microsoft Entra ID (Azure AD)	microsoft
Generic OIDC	oidc
Auth0	auth0
AWS Cognito	aws

Prerequisites

Before configuring a provider, register Lakehousecat as an application in the provider's console and gather:

• Client ID and Client Secret for the application/app registration
• The Redirect URI, if the provider requires you to register it up front (see Redirect URI below — most providers do not need this to be set manually)
• Provider-specific identifiers where applicable: Tenant ID (Microsoft), Domain (Auth0), User Pool ID and Region (AWS Cognito), Provider URL (generic OIDC)

Step 1 — Create the Credentials Secret

Client ID and Client Secret are never stored in the Lakehousecat CR. Instead, create a Kubernetes Secret in the Operator's namespace before enabling a provider. Each provider reads from a fixed secret name:

Provider	Secret Name
Google	lhc-oauth-google-secret
Microsoft Entra ID	lhc-oauth-microsoft-secret
Generic OIDC	lhc-oauth-oidc-secret
Auth0	lhc-oauth-auth0-secret
AWS Cognito	lhc-oauth-aws-cognito-secret

kubectl create secret generic lhc-oauth-google-secret \
  --namespace <operator-namespace> \
  --from-literal=CLIENT_ID="your-client-id.apps.googleusercontent.com" \
  --from-literal=CLIENT_SECRET="your-client-secret"

Repeat with the matching secret name and keys (CLIENT_ID, CLIENT_SECRET) for every provider you want to enable.

Provider silently skipped if the secret is missing

If a provider is set to enabled: true in the CR but its secret does not exist (or is missing a key), Lakehousecat does not fail the deployment. It logs a warning and skips that provider only — sign-in for that provider will not work until the secret is created correctly. Always verify the secret name and keys match the table above exactly.

Step 2 — Configure the Provider in the CR

Non-secret settings are configured under spec.auth.oauth in the Lakehousecat CR:

spec:
  auth:
    jwt:
      expiresIn: "2d"

    oauth:
      enableSignup: false         # Allow new users to sign up via OAuth
      mergeAccountsByEmail: false # Merge OAuth accounts with existing users by email

      providers:
        google:
          enabled: true            # requires secret lhc-oauth-google-secret
          scope: "openid email profile"

        microsoft:
          enabled: true            # requires secret lhc-oauth-microsoft-secret
          tenantId: "common"       # "common", "organizations", or specific tenant ID
          scope: "openid email profile User.Read"

        oidc:
          enabled: true            # requires secret lhc-oauth-oidc-secret
          providerUrl: "https://sso.example.com/.well-known/openid-configuration"  # required
          providerName: "Company SSO"
          scopes: "openid email profile"
          claims:
            username: "preferred_username"
            email: "email"
            picture: "picture"

        auth0:
          enabled: true            # requires secret lhc-oauth-auth0-secret
          domain: "myapp.auth0.com"  # required
          scope: "openid email profile"

        aws:
          enabled: true            # requires secret lhc-oauth-aws-cognito-secret
          userPoolId: "us-east-1_AbCdEfGhI"  # required
          region: "us-east-1"                # required
          scope: "openid email profile"

Field Reference

Provider	Required Fields	Optional Fields
Google	enabled	scope (default openid email profile), redirectUri
Microsoft Entra ID	enabled	tenantId (default common), scope (default openid email profile User.Read), redirectUri
Generic OIDC	enabled, providerUrl	providerName (default SSO), scopes (default openid email profile), redirectUri, claims.username/claims.email/claims.picture
Auth0	enabled, domain	scope (default openid email profile), redirectUri, issuerBaseUrl (auto-derived from domain if omitted)
AWS Cognito	enabled, userPoolId, region	scope (default openid email), redirectUri, authority, serverMetadataUrl (both auto-derived if omitted)

Every provider also reads CLIENT_ID and CLIENT_SECRET from its Secret (see Step 1) — these are not CR fields.

Redirect URI

Lakehousecat computes the redirect URI it actually uses automatically at runtime — you do not need to set it in the CR for most providers. The real routes are {apiPrefix}/oauth/{provider}/login and {apiPrefix}/auths/{provider}/callback.

The redirectUri field is only a fallback override for providers that require you to register an exact, fixed redirect URI in their own console (for example, the Google Cloud Console). Only set it if sign-in fails because the provider rejects the automatically computed URI — otherwise leave it unset.

Role Mapping from OAuth

Lakehousecat can automatically assign roles based on claims in the OAuth token:

spec:
  auth:
    roleManagement:
      enableOAuthRoleManagement: false
      rolesClaim: "roles"          # JWT claim containing user roles
      allowedRoles:
        - "user"
        - "admin"
      adminRoles:
        - "admin"

When enableOAuthRoleManagement is true, users whose token contains a role in adminRoles are assigned the Administrator role. All other users with a role in allowedRoles receive the User role.

Trusted Headers (Reverse Proxy)

For deployments where authentication is handled by an external reverse proxy (e.g., nginx, Traefik), Lakehousecat can accept authentication headers directly:

spec:
  auth:
    trustedHeaders:
      emailHeader: "X-Auth-Email"
      nameHeader: "X-Auth-Name"

When configured, the reverse proxy is responsible for authenticating the user and passing their email and name via the specified headers.

Common Pitfalls

• Wrong secret name or missing keys. The secret name must match the table in Step 1 exactly, and it must contain both CLIENT_ID and CLIENT_SECRET. A typo results in the provider being silently skipped rather than an error — check the Operator logs if a provider does not appear on the sign-in page.
• Setting redirectUri unnecessarily. In most cases Lakehousecat computes the redirect URI automatically. Manually setting it to the wrong value can break sign-in even though the provider itself is configured correctly. Only set it when the provider's console requires a fixed, pre-registered redirect URI.
• Missing required provider fields. Generic OIDC requires providerUrl, Auth0 requires domain, and AWS Cognito requires userPoolId and region. Without these, the provider cannot be reconciled even if the secret is correct.
• Forgetting to set enabled: true. Creating the secret alone does not activate a provider — it must also be explicitly enabled in the CR.

Setup Assistance

Configuring an identity provider requires registering Lakehousecat as an application in the provider's console (redirect URI, client credentials) and applying the configuration to the cluster. For detailed setup assistance, contact Lakehousecat support.