23.3 Beta 23.2 23.1 22.3 22.2 22.1 21.11

Google SSO Setup

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 setup the OAuth application.

Create an OpenID connect application

Follow this Google guide to create an OAuth application at Google. As you follow the guide to create the OAuth app, use the following inputs when you are asked for it:

The following configurations are based on the assumption that you want to host Redpanda Console so that it would be accessible using https://console.yourcompany.com.

  • Application name: Any descriptive name for your specific Console deployment (for example Console Analytics Prod)

  • Application type: Web application

  • Authorized redirect URI: https://console.yourcompany.com/login/callbacks/google

login:
  enabled: true

  # jwtSecret is a random string of at least 10 characters that must be the same for all Console instances.
  # This string is used to sign and validate the user session JSON Web Tokens (JWT).
  # If this string changes, logged-in Console users will be logged out and will have to initiate a
  # new session by logging in again.
  jwtSecret: ""

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

RBAC Google groups sync

If you want to bind roles to Google groups from a workspace organization you have to set up a service account, so that Redpanda Console can retrieve groups and their memberships using the Google Workspace API. Follow this guide to create the required service account and to delegate domain-wide authority to it. Make sure to create and download the service account key in JSON format.

You need to make the service account key (a JSON file) available to Console by mounting the file. The Console configuration expects you to specify the filepath to the JSON file so that 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, it is required that the service account impersonates such a user. Specify which user the service account shall 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 memberships, it will be printed in the logs. Group memberships will be cached for 15 minutes before they will be refreshed.