Google SSO Setup
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
Application name: Any descriptive name for your specific Console deployment (for example Console Analytics Prod)
Application type: Web application
Authorized redirect URI:
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: ""
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: "firstname.lastname@example.org". targetPrincipal: ""
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: email@example.com - kind: user provider: Google name: firstname.lastname@example.org 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.|