Google SSO Setup

This section pertains to Redpanda Console in a self-hosted deployment, and this feature requires an Enterprise license. To upgrade, contact Redpanda sales.

Integrating Redpanda Console with Google allows your users to use their Google identities to sign in to Console. This guide assumes you already have a Google account to set up the OAuth application.

Prerequisites

You must create an OpenID Connect (OIDC) application for your Google account.

Follow this Google guide to create an OAuth application. Provide the following inputs when you are asked for them:

  • Application name: Choose a descriptive name for your specific Redpanda Console deployment (for example Console Analytics Prod)

  • Application type: Web application

  • Authorized redirect URI: https://console.<your-company>.com/login/callbacks/google

The redirect URI is based on the assumption that you want to host Redpanda Console so it is accessible from https://console.<your-company>.com.

Edit the console configuration file

Edit the console configuration file associated with your deployment method and incorporate the details from your client application. For example, Kubernetes deployments use the values.yaml file. Linux deployments use the redpanda-console-config.yaml file, which is in /etc/redpanda.

login:
  enabled: true

  # jwtSecret is the secret key you must use to sign and encrypt the JSON
  # web token used to store user sessions. This secret key is
  # critical for the security of Redpanda Console's authentication and
  # authorization system. Use a long, complex key with a combination of
  # numbers, letters, and special characters. The minimum number of
  # characters is 10, but Redpanda recommends using more than 32
  # characters. For additional security, use a different secret key for
  # each environment. jwtSecret can be securely generated with the following
  # command: LC_ALL=C tr -dc '[:alnum:]' < /dev/random | head -c32
  #
  # If you update this secret key, any users who are
  # already logged in to Redpanda Console will be logged out and will have
  # to log in again.
  jwtSecret: ""

  google:
    enabled: true
    clientId: ""
    # ClientSecret is sensitive. You can also provide this config by setting
    # the environment variable LOGIN_GOOGLE_CLIENTSECRET.
    clientSecret: ""
    # The directory config is only required if you want to use Google
    # groups in your role bindings. This is described further in the next section.
    # directory:
    #   serviceAccountFilepath: ""
    #   targetPrincipal: ""

RBAC Google groups sync

To bind roles to Google groups from a workspace organization, you must set up a service account so Redpanda Console can retrieve groups and their memberships using the Google Workspace API. Follow this Google guide to create the required service account and to delegate domain-wide authority to it. Create and download the service account key in JSON format and mount the JSON file so it is available to Console. Specify the filepath to the JSON file in the Redpanda Console configuration file so it can be loaded at startup.

Because only Google users with access to the Admin APIs have access to Google’s Admin SDK Directory API, the service account must impersonate this user. Specify which user the service account will impersonate by setting the targetPrincipal to this user’s email address.

login:
  google:
    # The directory config is only required if you want to use Google
    # groups in your role bindings.
    directory:
      # Path to service account key in JSON format
      # For example: "/etc/mounts/google-sa.json"
      serviceAccountFilepath: ""
      # TargetPrincipal is the user that shall be impersonated by the
      # service account. For example: "admin@yourcompany.com".
      targetPrincipal: ""

Define role-bindings

When you set up the Google login configuration, you can bind Google users or groups to roles. Following is a sample role binding:

roleBindings:
  - metadata:
      name: Developers
    subjects:
      - kind: group
        provider: Google
        name: engineering@yourcompany.com
      - kind: user
        provider: Google
        name: john.doe@yourcompany.com
    roleName: editor
Group memberships will be resolved proactively in order to support nested groups. If the service account doesn’t have permissions to resolve a certain group membership, a message is printed in the logs. Group memberships are cached for 15 minutes before they are refreshed.

Suggested labs

Search all labs