Configure Google OAuth2 Authentication

To enable Google OAuth2, you must register a new application with Google.

Create Google OAuth2 Keys

In the Google environment, follow these steps:

  1. Navigate to the Google Credentials page.

  2. Click Create credentials > OAuth client ID.

  3. Select the Web application type.

  4. Enter Name , such as Kloudfuse.

  5. Enter URL of the kloudfuse installation in the Authorized JavaScript Origins.

    Example: kloudfuse.yourcompany.com

  6. Enter URL that has the /oauth2/callback of the kloudfuse in the Authorized redirect URIs.

    Example: kloudfuse.yourcompany.com/oauth2/callback

  7. Click Create.

  8. Copy the Client ID and Client Secret from the OAuth Client modal.

    Save it for next steps.

Enable Google Auth in Kloudfuse

Option 1: Use Client ID and Secret

In your custom-values.yaml file, add google client ID and secret:

 kfuse-auth:
   oauth2-proxy:
     config:
       clientID: "REPLACE_CLIENT_ID"
       clientSecret: "REPLACE_CLIENT_SECRET"
yaml

Option 2: Use Kubernetes secrets

In the kfuse namespace, create 2 kubernetes secrets:

  1. Create a secret called kfuse-auth-users as mentioned here.

  2. Create a new kubernetes secret, kfuse-auth-users; you can also update an existing secret.

    Use the output of cat users.txt| base64 as the value of users.txt entry in the secret.

    Use the edit command if editing an existing secret.

Edit Secret
kubectl edit secret kfuse-auth-users
Create kubernetes secret kfuse-auth-users
apiVersion: v1
data:
  users.txt: |-
    <base64-encoded-value-from-above>
kind: Secret
metadata:
  name: kfuse-auth-users
type: Opaque
yaml

  1. Create a new kubernetes secret, kfuse-auth-google.

    Use base64-encoded values for client id and client secret from kfuse-auth-users secret.

    To generate cookie secret, see the OAuth2 Proxy documentation for Generating a Cookie Secret.

    Create kubernetes secret kfuse-auth-google
    apiVersion: v1
data:
  client-id: <base 64 encoded google client id>
  client-secret: <base 64 encoded google client secret>
  cookie-secret: <base 64 encoded random value>
kind: Secret
metadata:
   name: kfuse-auth-google
type: Opaque
    yaml

  2. Include the two secrets in your custom-values.yaml file:

    Add secrets to custom-values.yaml
    kfuse-auth:
  oauth2-proxy:
    config:
      existingSecret: "kfuse-auth-google"
    htpasswdFile:
      existingSecret: "kfuse-auth-users"
    yaml

Configure Cookies

For some applications that must adhere to external compliance requirements, you may have to use custom configuration for cookies.

Cookie refresh functionality described in this section only works with OIDC-based authentication (such as Google OAuth2). It is not compatible with SAML-based authentication setups.
If after applying the cookie configuration settings you are not seeing the expected refresh behavior, try adding offline_access to the OAuth2 scope. This scope allows the system to obtain refresh tokens from the identity provider. Note that some providers (like Google) do not require this scope, while others may need it. For Okta configuration with offline_access, see Add offline_access Scope.
cookie-expire

Total lifetime of the session cookie. It the user shows no activity after this duration, the system logs the user out. The user must subsequently re-authenticate.

cookie-refresh

Interval at which OAuth2-Proxy automatically uses the IdP refresh token to renew the session cookie, and resets its TTL. This gets triggered by an active HTTP request, such as a click, navigation, or AJAX.

Activity

Any HTTP request sent to the protected App — page navigation, AJAX call, or link click. Passive actions like hovering or viewing the page qualify as Inactivity or Idle time.

Behavior

On each valid request, if the session cookie is older than cookie-refresh, OAuth2-Proxy calls the IdP to get a fresh access token, and the re-issuess the cookie with a full cookie-expire TTL. If no requests occur within the cookie-expire window, the session expires.

Idle Timeout/Inactivity Configuration for Kloudfuse OAuth2-Proxy

For example, to meet HIPPA standards, you must configure the cookie-expiry and cookie-refresh parameters for logout and other workflows.

To control automatic logout after a period of user inactivity, or idle timeout, tune the cookie-expire and cookie-refresh settings in your custom YAML.

To set the idle timeout, follow these steps:

  1. Choose the idle timeout period. This is the cookie-expire value.

  2. Set the refresh interval to a value shorter than the cookie-expire you chose in the previous step. This becomes your cookie-refresh value.

Log out after 30 minutes, renew session every 5 minutes

To log users out after 30 minutes of inactivity, and to renew their session every 5 minutes when active, add the following code to your custom yaml file:

kfuse-auth:
  oauth2-proxy:
    extraArgs:
      cookie-expire: "30m" (1)
      cookie-refresh: "5m" (2)
yaml
1 cookie-expire: "30m" means that the session lasts up to 30 minutes without activity.
2 cookie-refresh: "5m" means that for each request older than 5 minutes, OAuth2-Proxy will renew the cookie.
SSO/SAML flows

Refresh tokens must be valid; if the IdP’s refresh token TTL is shorter than cookie-expiry, sessions end earlier than the time limit set by cookie-expiry.

Basic Auth

No OAuth refresh flow. After reaching cookie-expiry or cookie-refresh values, whichever is shorter time, the user gets logged out, and must sign in again.